[ On Tue, March 26, 1996 at 22:01:25 (-0500), Chris G. Demetriou wrote: ]
> Subject: Re: another 1.1 to 1.1B (i386) upgrade report... 
>
> As i've said before, i don't think that only-source upgrades should be
> supported.

This is were we disagree entirely.  I believe this is the entire point
to having sources available for my OS.  It makes it easier for me to
manage custom changes and emergency fixes for a wide variety of target
systems, and allows me to upgrade to the latest proper release in a
minimum order of time for all such target systems.  Doing binary
upgrades, then merging my sources, and finally re-building once more,
esp. for a diverse number of systems, is a lot more work.

Further, given some of the special situations where we are working to
employ NetBSD, the common upgrade procedure will be effectively useless,
so we will need to build custom binary upgrade kits.  Moving towards a
scheme where full cross compilation is possible is necessary, and I
think you'll find that the ability to do source-only upgrades can begin
to lead you down this path if you're careful of where you step.

I know it's possible to build things by hand after culling approximate
procedures from the mailing lists, and finally end up with a complete
system, but it annoys me to no end that in the general case the
procedures I hack with are deterministic and could easily be automated.

> If they are supported via 'make,' they should be supported with a
> _different_ target than 'make build', so that non-upgrade users of
> 'make build' don't have to deal with the extra mess required.

I've no argument with calling it some other target.  'src-rebuild' would
be fine, or 'src-upgrade', or whatever is least confusing.

> Upgrades have little to do with dependency maintenance, save that if
> you do things in the wrong order you'll lose badly.

But that's what it means to have dependencies -- to do things in the
right order.  Make doesn't necessarily have to be used in such a way
that it determines the dependencies.  It can also be used more like a
deterministic state machine as it supplies all of the mechanisms
necessary to do so.

> For instance, in a source upgrade, assuming you're talking about going
> from one release to the next, there should be no nodes in your
> dependency graph that are 'potentially done already,' and your upgrade
> procedure is most easily expressed via a simple shell script.

Yes, I am talking only of release upgrades.  Yes this kind of thing can
be done in a shell script, but since make is already used as the build
tool it only makes sense (to me, at least) to include this ability in
the existing build environment.  It should be easier to do the
dependency maintenance if everything is all in one place, after all.

Note though that full release upgrades will generally cover the case of
-current's day-to-day/week-to-week upgrades, though obviously *not* with
the minimum possible amount of processing.

I believe my goals will both make it easier for folks to use the NetBSD
sources, as well as make the release engineering far more elegant and
easier to deal with.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>