Subject: Proposal for removing old O/S files
To: None <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 01/19/1999 10:41:54
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'
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)?