* Maintaining the build tools (autoconf etc) is currently too hard.
The maintainers have to struggle to write portable shell code; they have to constantly avoid the temptation to introduce new tool dependencies in the wrong place; they can't even rely on GNU Make. Those constraints really matter to a small number of packages (the "bootstrap packages") but could be reasonably relaxed for other packages. * Fork the build utils projects. Let's (more formally) identify a _small, finite_ set of GNU packages that should be maintained in such a way that they can be built in many environments (or for native GNU systems), even if no other GNU tools are already installed. Call this set the "bootstrap packages". Let's then formally identify a _subset_ of the bootstrap packages, which are those GNU tools that other (non-bootstrap) GNU packages are allowed to depend on for the build process. For example, GNU Make would probably be in this subset, as would a GNU shell. Call this set the "build environment packages". Let's then fork the build tools projects, permanently, creating a bootstrap-utils package. The bootstrap-utils package will _only_ support the bootstrap packages -- they can remove and refuse features for other packages. I would expect these forks to be very stable, tending mostly to be simplified over time. Then let's have a second permanent fork of the build tools projects to provide build-tools to all non-bootstrap packages. This fork of the build-utils can assume that all of the "build environment packages" have been previously installed. Setting up two permanent forks of the build tools separates the detailed, delicate work of preserving the critical bootstrapping paths from the potentially radical, sweeping work that could benefit all the non-bootstrapping packages. It's two very different kinds of work with incompatible goals -- so it should be two different projects. -t
