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

[Robert Millan]

Hi Nathan,

Well, these are just style issues that annoyed me when playing with
your packages (I made some minor improvements, see CVS), but if you're
going to be the primary maintainer for these packages, certainly
i have nothing to complain about. :)

I'd like to suggest, though, that for flexibility we have tools
that replace particular packages as separate, analogous packages too, eg:

make/pmake -> freebsd-make
byacc/bison -> freebsd-yacc
flex -> freebsd-lex

Otherwise if you want, say, FreeBSD lex and GNU bison at the same time
there's no easy way to have that combination.

On Mon, Jul 14, 2003 at 09:29:01PM -0400, Nathan Hawkins wrote:
> 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 
> 

-- 
Robert Millan