> 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
supported.

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?

No.


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.
	


cgd