Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!bacchus.pa.dec.com!news.crl.dec.com!shlump.nac.dec.com!shodha.enet.dec.com!alan
From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.unix.ultrix
Subject: Re: Ultrix 4.1!
Summary: We tried that once.
Message-ID: <1963@shodha.enet.dec.com>
Date: 12 Nov 90 01:42:10 GMT
References: <3738@vela.acs.oakland.edu> <3739@vela.acs.oakland.edu> <1990Nov11.225919.13038@comp.vuw.ac.nz>
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 58

In article <1990Nov11.225919.13038@comp.vuw.ac.nz>, ellis@rata.vuw.ac.nz (Brian Ellis) writes:
> In article <PCG.90Nov10180425@odin.cs.aber.ac.uk>, pcg@cs.aber.ac.uk
> (Piercarlo Grandi) writes:
> |> In general I think that upgrades are far more risky (difficult to get
> |> right) than full reinstallations, and take about the same time, for any
> |> Unix version.
> 
> If the upgrade is simply a "list" of the files that have changed, I could
> live with that. BUT I would want to know precisely which files have been
> changed, (and would be overwritten) in advance. 

	If you spend a little time figuring out the format of the
	distribution you can and see which files are on each subset.
	For tape distributions the 4th tape file is a tar archive of
	all the installation control files.  One of these is the
	inventory file (.inv).  The 10th field each line of this
	file is the filename.  More recently version of the "Guide
	to Preparing Software for Distribution on ULTRIX Systems"
	may have a good description of how the format of the dist-	
	ribution.  The V3.0 that I have handy doesn't have a good
	description.

> I would for example be quite happy with a tar file that I could load 
> into a seperate directory somewhere, and manually move the relevant 
> files across. I would be quite happy with some upgrade software subsets 
> - as long as I knew in advance which files were going to be overwritten.

	We tried this once.  I think it was an upgrade from ULTRIX
	V1.1 to V1.2.  It had two big problem, one that we could
	probably have solved.

	1.  The scripts that checked to make sure there was enough
	    disk space to unpack the archive sometimes lied.

	2.  People sometimes didn't read the installation guide to 
	    verify that they REALLY had enough disk space.

	#1 we could probably have fixed (and I guess did with setld),
	but #2 is very hard to fix.
	
> 
> I believe that I could apply an upgrade supplied in this fashion much more
> quickly than installing and configuring a new release.

	Many customers don't want to even do this much work (I know
	I don't).  The upgrades from V2.2 to V2.3 and V3.0 to V3.1
	were fairly simple and worked really, really well when you
	followed the instructions.

	The 45 days before the V4.1 upgrade would be available was
	an "AT MOST".  I'd expect to be available sooner, but I have
	no idea when.
> 
> Just my humble opinion...
> 
> Brian Ellis                               Computing Services Centre
-- 
Alan Rollow				alan@nabeth.enet.dec.com