Quoting Michael Goetze <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> 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
