Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!ll-xn!mit-eddie!bbn!bbn.com!rsalz
From: rsalz@bbn.com (Rich Salz)
Newsgroups: comp.sources.d
Subject: Re: OS upgrades
Message-ID: <565@fig.bbn.com>
Date: 30 Mar 88 16:02:42 GMT
References: <1682@desint.UUCP> <1007@mcgill-vision.UUCP> <46626@sun.uucp> <1703@desint.UUCP> <137@chem.ucsd.EDU>
Organization: BBN Laboratories, Cambridge MA
Lines: 25

When a release is sent out, the vendor should include a file that lists
the stat(2) information and a checksum of every file.  The first part of
upgrading a new release is to compare this file with the current state of
the system.  That way, if the checksum of /etc/rc.local is not what was
originally shipped, you can at least warn the sysadmin.  I wrote such a
program once, and the company used it all the time.  It's not hard, even
when you're selective (e.g., "do a stat of everything in
/rel1.2/xy/include except /rel1.2/xy/include/sys, and assume the
destination is /xy/include").  In fact, I recall that the UniSoft port
of SystemV had something like this.

One tricky part is proper updating of the file for maintenance releases.

It's almost always a mistake to blindly wipe out entire directories,
rather than inserting new files.  And requiring people to repartition
their disks shows a real lack of foresight on the vendor's part.

I remember being real pleasantly surprised by how nicely most upgrades
from mt. Xinu and Pyramid were handled.

This is an interesting discussion, but it's not really about sources;
where should it go?
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.