Rollback functionality for apt-rpm

[João Abecasis]

Hi everyone!

Panu Matilainen wrote:
> Took a bit longer than I hoped, sorry. Some additional comments / food for
> thought:

Apologies for my silence as well... for the record it is not my (our)
intention to just drop the code and be done with it ;-)

I've been busy porting the patch to debian's apt.

> - You certainly do NOT want to store rollback database in /var/cache/apt,
> that data is supposed to be just a cache that can be recreated at any time
> from information available elsewhere. 'rm -f /var/cache/apt/*.bin' is
> a common method for cleaning up the package cache if it has gotten screwed
> somehow. The package data can be restored from package indexes, the
> rollback history not. So I'd suggest moving it to /var/lib/apt (or rather,
> Dir::State) instead.

You're absolutely right. The transaction database and the
configuration files' backups, as well, should be treated as "state",
since they cannot be regenerated from other information. Noted.

> - For somebody who's concerned enough about the system state to bother
> with rollbacks, storing just the config files might not be sufficient. The
> package in question might have gone offline for whatever reason, and the
> non-config contents might have changed as well (be it a config file not
> marked as such or whatever). Storing the full package contents should be
> possible at least optionally I think. Which brings me to the next point...

This is a trade-off, I guess. Here we chose to leverage apt's
repository to keep the immutable files. Of course this requires that
old versions of a package remain available at the repository.

Taking this course lowers disk usage and allows for centralized
management of old packages, as opposed to replicating the history in
each individual system. For those interested, and in the cases where
upstream distributions don't guarantee availability of old versions of
packages, it wouldn't be too difficult to set up a private repository
for rollback purposes.

Thinking about it, it could also be nice to have centralized
management of the configuration backups and the rollback feature
itself... But I guess that's not for now ;-)

> - Rpm has native rollback capabilities since 4.0 or thereabouts. Did you
> experiment with using that instead of doing it all yourself? apt-rpm
> honors rpm configuration for creating rollback rpm's (in rpm terms called
> "repackaging") on transactions, what has been missing is a way to do the
> actual rollback via apt. I haven't actually looked into the details at all
> but it might be good/cool/nice to be able to use the native rollback
> capability where it exists and is usable (eg I don't know of rpm 4.0
> rollback quality :). OTOH Debian apt and (apt-rpm on rpm-3.x) could use
> the in-apt rollback support because nothing like that exists in dpkg.

Using native rpm rollback we'd also miss the ability to leverage the
contents of the repository. I guess native rpm rollback could be an
option but I think there's still room for the approach we followed.

I'll look into changing the Dir::Cache to Dir::State and marking
compilation of the rollback functionality as optional.

Thanks for looking into this! Thanks to everyone for the comments and support!

Cheers!


João Abecasis