In message <20021208073750.GS8398@mewburn.net>, Luke Mewburn writes:
>On Sat, Dec 07, 2002 at 11:03:22PM -0500, Steven M. Bellovin wrote:
>  | In message <Pine.NEB.4.33.0212071955390.12035-100000@vespasia.home-net.int
>ernet
>  | connect.net>, Bill Studenmund writes:
>  | >Why not use build.sh to make a release? It will make the sets for you. An
>d
>  | >if you do an unpriv'd build, you need to do something to get the
>  | >permissions right.
>  | >
>  | 
>  | The problem is that installing a release from sets is an annoying 
>  | process.  You have to zap all the things that a full installation 
>  | needs but you already have (i.e., root's crontab), and take the usual 
>  | care with /etc.  etcupdate is a big step forward, but I'm still not at 
>  | all satisifed with the ease of upgrading.  (Note:  this isn't to say 
>  | that tar-ing DESTDIR on top of the running system is easier -- it's the 
>  | same set of problems.  But I wish there were an easier way to keep 
>  | -current.)
>
>So don't extract the etc.tgz set then.

Sure -- except that there are lots of other things besides /etc/passwd 
and friends in /etc; there's fixed code and new functionality in
/etc/rc.d/*, for example.  
>
>I regularly upgrade my systems from "old -current" or "earlier release"
to "-current" or "head of release branch" by running an UNPRIVED
>DESTDIR!=/ build, creating the sets, extracting all sets *except*
>etc.tgz, and then running one of:
>
>    a)	if sources are available:
>		cd /usr/src
>		./etc/postinstall -s `pwd` check
>		./etc/postinstall -s `pwd` fix

Hmm -- 'man postinstall' (on both -current and 1.6) doesn't seem to 
work.
>
>    b)	if no sources available, but I have etc.tgz:
>		mkdir /tmp/foo
>		cd /tmp/foo
>		pax -zrvpe -f /path/to/etc.tgz
>		./etc/postinstall -s `pwd` check
>		./etc/postinstall -s `pwd` fix
>		cd /
>		rm -rf /tmp/foo
>
>This latter step handles all the "upgrade" issues for me of source
>related stuff.   I don't use etcupdate, but I believe it can help with
>some of the other "etc upgrade" related issues...
>

These tools are nice steps forward.  Daniel Carosone's rsync 
mechanism is an even nicer way.  But that's not my point.  The point is 
that it's too hard, and sometimes needlessly too hard.

First, /etc is a mess.  It was good that most executables were moved to 
/sbin, a dozen or so years ago.  But /etc still has a mix of system 
scripts, per-site data, and per-machine data.  Worse yet, we don't have 
good tools for users to deal with this, *especially* in a multi-machine 
setup.

Second, we package releases wrong.  etc.tgz perpetuates the confusion 
from /etc (and, I might add, /var).  The release-dependent files, such 
as /etc/rc.d, belong in one place; things like /etc/passwd and
/var/games/rogue.scores belong in another.  In fact, those latter -- 
the null or simple stylized files that need to exist (i.e.,
/etc/daily.conf (we can argue another time if it should be /etc/daily
or /etc/daily.conf that reads in /etc/defaults/daily.conf) should be 
generated by tiny shell scripts (most of which would say 'touch file'),
rather than being extracted.

Following from that, there should be conversion tools -- scripts to add 
new lines to /etc/passwd, for example, taking care to ensure that 
they're only added if needed.

Finally -- and only after that is done -- we should worry about making 
life easier for folks who have made their own, personal changes to any 
system files.  Wouldn't it be nice if, when doing an install, you were 
told "you changed /foo/bar" or "you changed /foo/bar/bletch/bazz.c"?
Every time I do a release upgrade, for example, I have to remember to 
make a certain tweak to /sys/dev/pci/if_ex_pci.c, or one of my machines 
won't be able to talk on the net.  Similarly, I have to remember a 
ghastly hack to dhcp/common/options or my laptop won't be able to talk 
to the dhcp server at many Marriott hotels.

Note that all of these problems apply to folks who don't track 
-current.  It's probably worse for them -- -current users, at least, do 
upgrades frequently enough that they're used to it, and have built 
tools and work-arounds....


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)