[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Glibc and NetBSD

On Wed, Jul 24, 2002 at 01:58:00AM +0200, Andreas Schuldei wrote:
> * Michael Graff (explorer@flame.org) [020724 01:28]:
> > IMHO, this is the wrong way to look at things.  If packages are so
> > linux (and glibc is linux slanted, IMHO) they should be fixed to be
> > more unix, not making the unix world more linux.
> The debian packages would need work to build cleanly on the bsd
> libc. Often helper programms like configure, automake and libtool
> are not working as expected. It means a lot of work and time and
> hard feelings (do never underestimate the social side!) to break
> a lot of peoples packages and keep them working. Please consider
> the entrence we make when beaking every package around and
> demanding submission^Wcooperation from people.

I agree with the opinion that BSD libc is the way to go. I do, 
however, think that we should offer an alternate build env to
support glibc.

One way around the "social side" would be to have the BSD
buildd (or the people building the packages by hand, initially)
mark BSD-specific compiling bugs as wishlist instead of their
normal severity, until the BSD port is largely finished. In an
ideal world, the BSD-specific bug wouldn't be submitted without
a patch included, since the maintainer likely has no BSD system
on which to develop a fix.

> on the other hand debian is known to try to be correct. if the
> bsd libc fits the bill and there is a solid base, why not wrack
> it all and start over again with bsd libc?

We should use whatever libc is the established standard on the
platform we are trying to support. This means glibc on Linux and
HURD, and the native libc under NetBSD, FreeBSD, Solaris, AIX,
HP/UX, or whatever else people decide to mess around with.

Providing a glibc compatibility environment is a good thing, but
we should be striving for native libc support whenever possible.
One way to think about this is: How can we best improve the
overall quality of our packages? I firmly believe that making the
packages more portable is definitely an improvement.

> Please note that the debian openbsd system will use the native
> system tools and libs for security reasons, for a (long) start. I
> will however try to use the big packages like perl, apache, MTA
> etc from debian, since they are not really audited in openbsd
> anyway and the packages provided in debian are of higher quality
> then i could hope to achive on my own. 

That's the idea...for anything not part of the 'base' distribution
(as defined by whatever platform you're building for), we should
be using the standard debian source packages. But they (perl, 
apache, MTA, everything else) should be compiled against the
standard libraries for the platform we are supporting whenever

Elie Rosenblum                 That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer             - _The Necronomicon_

To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: