Subject: Re: Package Paths Proposal v3
To: Curt Sampson <cjs@cynic.net>
From: Simon J. Gerraty <sjg@quick.com.au>
List: tech-pkg
Date: 12/28/1998 23:04:09
>> A more unique suffix than ".old" should be chosen here if this is
>> automated. Users may have .old files flying around for themselves, and we
>> should better not nuke their files away. Maybe something like ".oldpkg"
>> would be better.
You might want to allow the admin to pick the ".old" suffix at upgrade time.
This simple expedient has several benefits.
For example the "install_files" tool from my "configs" package saves files
that it is updating (exactly how depends on some details
which are not important here). Typically the first time "configs" is run
on a system, the old suffix defaults to .FCS so that the original vendor
files will be kept despite future updates via configs - which is important
if you need to say put /usr/lib/sendmail.FCS back before a vendor patch
will apply... on subsequent runs the suffix defaults to .old
However the admin can simply set OLD_EXT=.ch1234 or anything else and the
files will be saved with that suffix. This is very handy for upgrades being
done under a site's change managment control{1}. If the update later needs to
be backed out, the admin can run "uninstall_files" .ch1234 to back out
the changes (as far as that is possible). The admin has several other
options too - all essentially enabled by being able to pick the suffix
that old files will be saved with.
{1} I'm talking about sites where "you cannot do _anything_ to an important
system without a tested backout plan" - reinstalling from long lost media
does not constitute a backout plan :-)
--sjg
--
Simon J. Gerraty <sjg@quick.com.au>
#include <disclaimer> /* imagine something _very_ witty here */