perry@vu-vlsi.UUCP (Rick Perry) (03/10/87)
In article <2606@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >... When we upgraded >from 4.2 to 4.3, we had a hell of a time tracking down *all* the local >stuff and made a decision that as much as possible we were going to put all >the local stuff in separate directories from now on. 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. The only Unix system I am familiar with is Pyramid, and it may interest some to know what they provide when doing upgrades... Pyramid provides some programs called 'rls' and 'rlscmp' plus a list of files (including stuff similiar to 'ls -lg' plus a checksum) as they should be if you haven't modified anything in the old release. With these programs you can easily generate lists of what files have been added and what files have been changed from the standard distribution, then you can easily save all those files before wiping everything out and loading the new release. If this is not a standard Unix thing provided with new releases it should be! It does give you some degree of confidence as all of the old root and /usr is wiped out as the new ones are loaded to know that you've saved anything that was changed or added locally. Still, it did take me a whole day (that's a 24 hour day) to get things back to normal after the last upgrade, the biggest problem being files that we modified slightly (like /etc/termcap) and wanted to have both the local mods plus the new upgrade version mods in the current system. ...Rick ..{cbmvax,pyrnj,bpa}!vu-vlsi!perry perry@vuvaxcom.bitnet
forys@boulder.UUCP (03/11/87)
In article <648@vu-vlsi.UUCP> perry@vu-vlsi.UUCP (Rick Perry) writes: > Pyramid provides some programs called 'rls' and 'rlscmp' plus a list > of files (including stuff similiar to 'ls -lg' plus a checksum) as they > should be if you haven't modified anything in the old release. With these > programs you can easily generate lists of what files have been added and > what files have been changed from the standard distribution [...] Why not just do an `ls -lt' of the directories? It gets you a sorted list of everything that's been changed. Then, all you gotta do is meticulously plow thru each directory and check out the modified files (I've actually managed a couple *clean* upgrades this way). 'cept, of course, I *always* forget to do a `df' before starting. Oh yeah, and you need a pizza too... --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-6096) forys@Boulder.Colorado.Edu -or- ..!{hao|nbires}!boulder!forys
rmg@mips.UUCP (03/11/87)
In article <648@vu-vlsi.UUCP> perry@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