[Glibc-bsd-devel] Re: comments on the FreeBSD packages

[Nathan Hawkins]

Robert Millan writes: 

> 
> [ CCing to glibc-bsd-devel@lists.alioth.debian.org ] 
> 
> Hi! 
> 
> Nathan, I'd like to make some comments/suggestions on the FreeBSD packages: 
> 
>  - how about making all of it into a single multi-binary package? it has
>    the advantage that it's less work for maintainance and we don't have
>    to worry about keeping interfaces in sync (e.g: program requiring features
>    in newer libc version, etc)

I did that before, but I found that you basically get a gigantic tarball, 
and it is a pain when doing new uploads, especially for minor upgrades. 
Also, rebuilding _everything_ takes forever. 

I plan to write up scripts to create the tarballs from CVS, so I can track
 -STABLE. :)  I also want to look into means to enable the use of multiple 
versions of the core utilities (i.e. ifconfig, mount, etc.), and have a 
binary wrapper that detects which kernel is running, and exec's the right 
binary. 

>  - i think we should have a separate /usr hierrachy for the FreeBSD stuff. Its
>    bin directory could contain things like:
>      - cc: you cross-compiler script, so we don't have to patch upstream
>        sources to replace cc with i386-freebsd-gcc

Actually, those patches are ridiculously easy to maintain. Look under the 
debian/ap directory. Those files are processed by a program called 
autopatch, which is usually in debian/mk, and autopatch recreates the diffs. 
It's nicely automated, and very painless.  So much so that I've been 
considering packaging autopatch. 

Also, I rather like being able to have FreeBSD stuff in /usr/bin. :) 

>      - uname: script that echoes "FreeBSD" on -s, and fallbacks to real uname
>        for any other options
 

IMHO, uname -s should be FreeBSD. uname -s on Linux is Linux, not GNU/Linux. 
Things that look at uname -s just simply should be changed, that's an awful 
way to do things. 

>      - yacc,lex,make: FreeBSD versions of the utils, so we don't have to patch
>        upstream sources (eg, s/make/fmake/g), and we can avoid kludges like
>        conflicting with byacc or pmake

Actually, the conflict with pmake was that pmake uses /usr/share/mk, and so 
does freebsd-make. I just haven't got round to doing anything about that. 
FWIW, freebsd-make mostly will build with pmake, but the share/mk directory 
doesn't. 

>    this way, you'd get a FreeBSD build environment by simply exporting a new
>    value to the PATH variable.

You can now, by setting CC=i386-freebsd-gcc. As for lex and yacc, these are 
actually flex and byacc, just forked slightly. Those problems may go away 
someday.  For now, it's not a very great hardship to use the 
freebsd-kbuildutils package. It has the alternate versions of flex and 
byacc. At some point, I'll figure out how to get them to install without 
conflicts. 

   ---Nathan