[ On Thursday, November 30, 2000 at 15:17:35 (-0500), David Maxwell wrote: ]
> Subject: Re: Help wanted with following NetBSD-current
>
> The problem is that the system bootstraps itself - any part of the
> OS might be need updating to build the next version of the OS.

Strictly speaking that's only ever true when some system program feature
changes in a non-compatible way *and* the build requires the new feature
and won't work at all, or won't work correctly, with the old feature.

This almost only ever happens with parts of the system that are directly
involved in the compilation and installation of programs, i.e. with some
of the more complex build tools like make, yacc, lex, gcc, install, etc.

> There's no practical way (that I can think of) to maintain all the
> steps you might have to follow at any given time, because they
> constantly change.

A very few such tools are already handled as well as can be by "make
build", such as the updating of the /usr/share/mk files early in the
process, just as are obvious global dependencies such as header files
and libraries.  There are even weird checks now to make sure you have
some recent EGCS version of the compiler, and if not it builds and
installs it before going on (if it can -- cross-build support isn't all
there yet, so it doesn't work if you've got DESTDIR set).

While there's no complete solution to the entire problem, some of the
most common errors that people *still* commonly have in tracking current
would seem to be solved by simply ensuring that the obvious build tools
are always built and installed first.

For example it puzzles me to no end why "make build" still, after all
these years, doesn't first re-build and re-install 'make' before
installing and the new /usr/share/mk files.  Without too much trickery
the "make build" could even bootstrap itself up such that it restarted
from scratch after doing this!  I haven't done the latter, but I've had
my "make build" always re-install 'make' very early in the process for
some time now and it's eased the process for me immensely.

Even the recent rpcgen fiasco could possibly have been automatically
dealt with by a tiny fix to "make build" and the best part would have
been that the next time someone changed it "make build" would just "Do
The Right Thing(tm)" in the first place!

The list of critical build tools that are most likely to suffer from
incompatible forward-only changes isn't likely to be all that big, or
hard to generate; and it probably wouldn't be all that hard to get it
into a half-assed guess at the right order such that "The Right
Thing(tm)" would always happen for all of them.

Of course for those of us who prefer to run the entire build
(i.e. everything but the "make install") as a non-root user, well things
get a bit more complex....   :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>