[Rpm-maint] Removing repackage and (auto)rollback?
pmatilai at redhat.com
Thu Mar 6 08:34:34 UTC 2008
On Wed, 5 Mar 2008, seth vidal wrote:
> On Wed, 2008-03-05 at 16:40 +0200, Panu Matilainen wrote:
>> Indeed. The thing here is that if you limit the rollback scope to just
>> config files, things suddenly become far more manageable. It wouldn't cost
>> an arm and a leg to (optionally) store the entire config file history
>> separately, say, in a real SCM or something resembling one.
>> Imagine being able to diff the config files between this and the previous
>> (or a year ago) version, or what's currently on the system vs what the
>> package contained when originally installed. Etc.
>> I'd guess that quite a few sysadmins would just love that...
> This might be off-subject for this list but maybe a plugin for yum that
> pre trans:
> for pkg in transaction:
> if the pkg is an update,
> grab up the current config files and check them into an scm
> do the transaction
> post trans:
> for pkg in transaction:
> check the new versions (if any) into the scm
That'd be the "optimistic" version more or less, but to protect against
nasty scripts in packages that mess with config files of other packages
I think it'd have to be more like:
- Tag *all* config files on a system for current state (except for initial
install where there's obviously nothing to tag)
- Stash pristine config files from the packages into a "vendor branch"
(in CVS terminology) in the scm before anything, including packages own
scripts, has a chance to mess with them.
- Tag *all* config files on a system for current state
Now you could do a diff <pretrans tag> <posttrans tag> to see everything
that changed in the transaction wrt configs, see what dirty deeds the
scripts did to your configs etc. For ultimate accuracy you'd have to tag
everything between each and every package in transaction, then you could
pinpoing exactly which package did what but that gets a tad heavy...
Of course there are tons of details to figure out: I'm not going to bundle
an scm into rpm, so there's not going to be any scm during initial
installation. To avoid making the initial install a completely different
special case, rpm on the lowest level would probably need to deal with
this on filesystem level, ie just put a separate copy of the config files
somewhere discoverable and safe and something else (via hooks from rpm)
would deal with the dirty details of dealing with the scm. I dunno, I
don't have a design for any of this, just kicking ideas around to see if
anything useful comes up :)
- Panu -
More information about the Rpm-maint