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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
