proposal to fork the build-tools projects

[Tom Lord]

* 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