Re: libc strategy
Quoting Michael Goetze <mgoetze5@yahoo.com>:
> But here you're jumping to conclusions. The BSD libc is not some relict
> of 20 years ago, it is a living, breathing entity. And, as has been
> pointed out, pretty much all of the GNU tools already run on it without
> problems. Indeed, any program that is properly autoconf'ed should run
> on BSD with no problems. And, if it doesn't, then it'll be our job to
> ensure that it does - which should also produce goodwill in the BSD
> community, because we'd be expanding the range of applications
> available to them.
Good point, and goodwill with the BSD community at large would be very
nice, consider that (if successful) Debian would be becoming a part of
that community. As for assuming it would be a major pain in the ass
to convert many packages to BSD libc, I'm assuming the difficulties
reported earlier with getting Debian's package tools working are going
to crop up many other places as well, even if not in the GNU tools.
> > I'm wondering if a third option isn't possible: (c) create a new
> > library that runs on top of BSD libc that simply takes glibc calls
> > that aren't in BSD libc and provides them, or functions that operate
> > differently would be "wrapped" by our glibc compatible version.
>
> This is a Bad Idea(tm), because you'd have to find someone to put out a
> new version everytime a new version of glibc and/or BSD libc came out -
> and it wouldn't be a trivial task. If it were a one-time hack, maybe,
> though even then it wouldn't be the Right Thing To Do.
I don't think it would require that much work, actually. I'm assuming
most of the changes to BSD libc and GNU libc would not actually require
changes to the GNU->BSD libc library, perhaps a recompile, but unless
there's a fundamental change in how one of the wrapped functions
operates, I don't see why changes on the BSD side would require any
changes at all. As for the GNU side, obviously any time a new function
is added to glibc, it would need to be reimplemented on top of BSD libc
in the GNU->BSD library. But how often is that, and for that matter
how critical is it that it be updated that regularly? If glibc was
*that* unstable, most of the binaries on my system wouldn't be
functional, whereas in fact many of them were compiled years ago and
work fine. I don't think it would be nearly as much work as you think.
But I have no problem with the idea of this being a transitional stage
while packages get modified to work under BSD libc (or glibc get ported
if we went that route). I'm just trying to think how we could jump
start this baby -- we can worry about the long-term solution, well, in
the long-term. It seems to me like it would be the quickest way to
get things going. Sometimes Doing-It-Right(tm) from the start is a
good idea, other times it's best to provide an interim solution. I
think this may be a case of the latter. (I'm mostly worried about the
former simply never getting off the ground...)
--
GT <gt@dreamsmith.org> http://www.dreamsmith.org
"We don't receive wisdom; we must discover it for ourselves after a
journey that no one else can take for us or spare us." - Marcel Proust
Reply to: