upgrades and local mods (was .l vs .1)

[rmg at mips.UUCP]

In article <648 at vu-vlsi.UUCP> perry at vu-vlsi.UUCP (Rick Perry) writes:
>   This discussion started with ideas on where to put and how to name
>local man pages, but I've seen a few comments about how much trouble it
>is to find local and locally modified stuff when doing an upgrade.

....[description of tools provided by Pyramid for detecting local
     modifications to be saved at upgrade time]....

Getting a system back into the desired local configuration after an update
can be a real pain. I shudder to recall performing "updates" in which the
root and /usr file systems must be re-made from scratch.

At MIPS, we are currently supplying releases with an installation procedure
which knows how to install either from-scratch (starting from unformatted
disk if necessary) or as an update. In the latter case, the installation
procedure will determine what files present in the new release have been
modified locally since the last release was installed. These files are saved
automatically. In cases where doing so would not endanger the correct
operation of the new release, the local changes are restored after the
files from the update have been installed.

In some cases, local versions of files are converted at install time. In
converting from the 4.2 to 4.3 release, for example, the group "find" is
added to the local /etc/group file without disturbing local group
definitions. Another example: when converting from a non-NFS to an NFS
release, the local /etc/fstab is automatically converted to the new format
required by the NFS utilities.

There are still some cases where we don't perform automatic conversions, but
in all of these we do post an advisory note that local modifications should
be re-integrated to the file installed from the new release. Most of these
could be automated if deemed worth the time to write the conversion scripts.

In most cases, significant upgrades (such as the non-NFS to NFS update)
require no extra (other then performing the installation) administrative
effort to get the system back to its old lovable local self.

I'm curious as to the Unix OS release update facilities provided by other
vendors. Some specific questions that come to mind follow. If you have a few
moments, please let me know how your favorite (or most accursed) OS handles
these issues. (Please respond to these by mailing at me... I'll summarize to
this group).

------

What OS? (derivation [BSD 4.n, SysV Release n, etc], release, hardware
target, software vendor).

Do they require that filesystems be re-made when installing the OS?

Are there provisions for detecting which files have been locally modified
since the previous release was installed? (And, if you know, how is it
determined that a file has been modified?)

Are these locally modified files saved by the installation procedure?

Are they restored after the installation is complete?

Are any locally modified files actually converted for use with the new
release by the installation procedure?

How well does all of this work?

-- 
- Rich Geiger
{decvax,ucbvax,inhp4}!decwrl!mips!rmg
MIPS Computer Systems, 930 E. Arques Ave., Sunnyvale, CA 94086  (408) 720-1700