On Wed, Mar 10, 2004 at 08:32:15AM +0100, Mgr. Peter Tuharsky wrote: > Does somebody know what I'm talking about?
Yes. In my opinion, the most serious issue [and not one I have a good solution for] is the state of glibc: [1] Upstream sources generally are not buildable on older versions of the tool chain. This has security implications, and is a general pain, but [2] Because of portability issues, it can be very hard to figure out what the proper solution is to any specific problem, and [3] Building the toolchains (binutils, gcc, glibc) involves a lot of knowledge of largely undocumented features. [And those features aren't designed to be independent of each other -- changing one option might involve changing a few others just to allow the build to work at all.] Ultimately, this means that only experts can configure the thing properly. To some degree (especially for native builds for x86), this doesn't matter ["it works, what's your problem?"], but the underlying rigidity of the system hurts us. We get some flexibility back because our maintainers stick to fairly stable back versions of the code and maintain a set of deb patches, but ultimately this is caught in the same interlock as the upstream glibc. Until we have a tool chain which can be built on any system [for example, an old a.out linux] and be identical to one built on a modern system, we're going to be stuck with some elements of this issue. And when I say "we", I don't mean just debian, but everybody else (including "source only" folks such as gentoo). But really solving this problem is incredibly difficult -- and it's not completely a glibc issue because [for example] bsd is faced with variants of the same problem using their own libcs (that's libc, plural, not lib cs). The general upgrading problem is a hard issue, and solving it involves a lot of trade offs. [And this is related to the reason it's so hard to get people to switch from non-free operating systems...] -- Raul
