[Rpm-maint] Removing repackage and (auto)rollback?

[Panu Matilainen]

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
> did:
>
> 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:

Pre trans:
- Tag *all* config files on a system for current state (except for initial
   install where there's obviously nothing to tag)

In trans:
- 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.

Post trans:
- 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 -