Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!oliveb!sun!plaid!chuq
From: chuq@plaid.Sun.COM (Chuq Von Rospach)
Newsgroups: comp.sources.d
Subject: Re: Wiping out /bin in OS upgrades
Message-ID: <47576@sun.uucp>
Date: 30 Mar 88 18:12:08 GMT
References: <1682@desint.UUCP> <1007@mcgill-vision.UUCP> <46626@sun.uucp> <1703@desint.UUCP> <756@stride.Stride.COM>
Sender: news@sun.uucp
Reply-To: chuq@sun.UUCP (Chuq Von Rospach)
Organization: Fictional Reality
Lines: 60

>>... Too bad Sun doesn't see fit to document Chuq's
>>personal habits as a "you must do it this way" procedures.

Let me ask a semi-rhetorical question. I don't want to start a flame war,
I'm really curious how to do this 'right' since I don't see a way:

If you look at the shell script I posted, one of the files I modify is
/usr/ucb/quota. Now, I'm going to upgrade my system. How, without telling
the upgrade process what that change is for, does the upgrade process do
the right thing?

	o You can tell the file is changed because the checksum is different,
	right? But how much information about checksums do we keep? The
	previous release? What if I'm upgrading from 3.2 directly to 3.5?
	Or for 3.0? 2.2? Should the upgrade notice that the version of
	/usr/ucb/quota isn't from ANY sun tape?

	o What about patches? Suppose I'd modified quota because the new 
	version fixes a bug? (for the record, this isn't the case....) And
	say that bug is fixed in the release I'm installing? Shouldn't it
	ignore the fact that the binary is patched and install the new
	standard version? How do you tell this?

	o Local changes? I've modified quota to do something different than
	the standard release. How does the system recognize this as a
	legitimate change that it should NOT override? And how does it tell
	that this is really a legitimate change and not some trojan horse
	that someone ELSE put into your system for you?

	o And what if there's significant new functionality in our version
	of the binary that doesn't get overridden because your private patch
	means we don't install over it. Let's even say that the program
	involved is, say, /bin/login. Now you can't log in, because your 
	old private version isn't compatible with our new system, and we
	didn't install our copy of the new, improved program.


Private changes in the system directories aren't easy. There are so many
possibilities and the ways of dealing with them are exceptionally complex.
And there are no really clean answers that don't involve manual intervention
anyway. There's no way to install on a modified system directory structure
and do it cleanly without adding a lot of complexity to the install system
AND requiring a knowledgable installer. 

Rather than building all the complexity (and likely a few bugs) into the
install program, especially when it won't really solve the problem
completely, doesn't make sense. In my eyes makes more sense to have the
administrator keep track of what they've changed and re-install them after
they upgrade. This gives them a chance to figure out whether the changes
they have they really still want (or need) and deal with changes in
functionality or filesystem structures. And if you keep documentation and
copies of all the changes in the system trees, you no longer have to back up
those file systems, saving tapes and time -- and you no longer have ulcers
when disks go down. You re-install, and restore your changes.


Chuq Von Rospach			chuq@sun.COM		Delphi: CHUQ

    Even with my limited Chuq I got into a few conversations, and one man wanted
    to argue politics with me. -- Lisa Goldstein (After the Master, Asim, 5/88)