Subject: Re: another 1.1 to 1.1B (i386) upgrade report...
To: Greg A. Woods <email@example.com>
From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
Date: 03/26/1996 22:01:25
> Do you have any alternate suggestions as to where/how a source upgrade
> procedure might be encoded?
As i've said before, i don't think that only-source upgrades should be
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 say more to this below...
> Is not a dependency maintenance tool one of
> the better implementation environments for such a task?
Upgrades have little to do with dependency maintenance, save that if
you do things in the wrong order you'll lose badly.
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.
If you're talking about going from -current "releases" to other
-current "releases" or to real releases, then you need some way to
encode the day-by-day differences that may arise, and I can't think of
a clean way to do that with the most common 'dependency maintenance'
tool (make), at least.
In other words, i'd say:
(1) if the project wants to support source upgrades to
releases from other releases (and i would say that it
should not), then those upgrades should consist of one or
more shell scripts and some documentation, and
(2) upgrades to and from various versions of -current
_should_ be done using the current-users mailing list
and posts thereto as a guide.