Re: libc strategy
> I'm not sure if it would be very easy to do, but I don't think it
> matters much. What we need to do is make standard Debian packages
> compile under Debian/BSD, same as all the other Debian ports do --
> if this is to be a true Debian port, we'll need to be able to take
> a standard Debian source package and have it compile under debian-bsd
> as easily as it compiles under debian-sparc or whatever. We don't
> want to make whole new packages, nor do we want to use *BSD pkg
> stuff.
> We want to do it "The Debian Way(tm)".
That's right. After all, the big deal about this, as I see it, is
getting the quality Debian packaging (that includes all the hard work
done by package maintainers) together with the quality BSD kernel.
> Mostly what's been discussed in order to make this feasible is to
> either (a) port glibc to BSD, or (b) patch existing packages to work
> with BSD libc. But apparently porting glibc to BSD would be a major
> pain,
Well, beyond our resources, anyways. The GNU people do want glibc to be
portable, and I expect Debian/BSD would provide some good incentive for
them to put some effort into the matter. But, at this stage of the
project, with the resources we have, it's pretty much out of the
question.
> and patching every existing package that doesn't work with glibc
> would also be a major pain.
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.
> 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.
> It seems to me this would be easier than either (a) or (b).
Not much easier than (b), if at all, and not nearly as worthwhile.
> It would give us glibc compatibility for the GNU tools
Don't you worry about GNU tools... they're generally well-written and
coded portably. It's all that other stuff we've got to consider. :-)
- Michael
=====
"I wanted to change the world. But I have found that the only thing
one can be sure of changing is oneself."
-- Aldous Huxley
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Reply to: