Here's a rough idea for making upgrades allow for the removal of files
that have changed location (/sbin/nfsd to /usr/sbin/nfsd is the first
example that comes to mind).

1)  We keep all the old locations of files somewhere (ie, just
    /sbin/nfsd).  The first place I thought of is /etc/outdated.files
    but /etc may be on a read-only filesystem and this could cause
    problems - see step 3 for why and the last paragraph of this message
    for a small discussion about this.

2a) For binary releases, /etc/outdated is put in place by a "make
    distribution" in /usr/src/etc, and is in the base set.  This way,
    every time a binary release is made this file will be reinstalled.

2b) For source code upgrades (ie, make build), hopefully people
    will see an announcement on current-users that such-and-such a
    binary/file/etc has moved, and all they need to do is copy the
    updated /usr/src/etc/outdated.files to /etc/outdated.files.  This
    would also be an easy answer for the FAQ pages.

3)  In /etc/rc, we look or the outdated file list and move both its
    contents _and_ it.  Something like

	if [ -f /etc/outdated.files ]; then
		echo -n 'Removing outdated/relocated files:'
		xargs rm -f < /etc/outdated.files
		rm -f /etc/outdated.files
		echo ' done'
	fi
    This way, the work is done only once for each upgrade.

Does this sound workable?  I toyed with the idea of getting sysinst to
handle the removal of the contents of /etc/outdated.files, but there's
always going to be the cases of people who don't use sysinst to upgrade
their system, and the people who do source code upgrades.

I'm guessing that we've never removed an entire directory hierarchy
before - if we have it's an easy change from "rm -f" to "rm -rf".

The only problem I can see is the location of the file wrt/ a read-only
/etc.  Is this too much to worry about, or would it be better to put the
file in /var somewhere (say /var/db)?

Simon.