Rollback functionality for apt-rpm

Panu Matilainen pmatilai at laiskiainen.org
Thu Nov 30 00:28:27 PST 2006


On Wed, 29 Nov 2006, João Abecasis wrote:

> Hi everyone!
>
> I'm a developer with Caixa Mágica (the portuguese distribution of
> Linux!), where we use a customized version of apt-rpm as our main
> package manager. Our customizations amount to a "rollback" feature,
> which we'd like to contribute back into (your) mainline. To get the
> ball rolling, I've prepared a patch against current svn (revision 272)
> and hopefully, it's attached to this message... I'd like to hear your
> feedback on the patch and to understand what it'll take to merge the
> code.
[..]
> So what is this rollback feature, anyway? Basically we keep an
> activity log of apt-get transactions (install, remove, upgrade, etc.)
> and it allows transactions to be rolled back by ID. A backup of
> configuration files is kept on upgrades so they too can be rolled
> back. This feature was originally developed by David Pinheiro as part
> of the EDOS project (http://edos-project.org). David is no longer
> working with us, but he is always at the distance of an e-mail (I'm
> CC'ing him, btw).

Awesome, I know some folks who are going to wet their pants over this :) I 
certainly want to get this merged in one form or another, no question 
about it, the rest is more or less details.

I've only had a quick glance over the patch, but one immediate concern is 
that this adds a hard dependency on sqlite3. I've no idea if it's 
buildable (without upgrading like 50 other packages) on rpm-4.0 era 
systems (eg RHEL 2.1). Dag / Axel, comments? Breaking those systems is not 
really an option at the moment as support for old systems appears to be 
one of the bigger "selling points" of apt these days. Another thing is 
that I'd like to keep thing is that I'd like to keep the external hard 
dependencies to minimum.

In short, I'd like to see a build-time option for disabling the rollback 
support. The code (naturally) touches some of the core paths, ifdef'ing 
all that is not a very attractive option. One possibility I suppose would 
be to abstract the database access and have a dummy class for the case 
where sqlite isn't available. That would also open the possibility for 
other db backends - I can imagine somebody might want to hook this up to 
some central database server in an enterprise setting.

However if sqlite3 is easyish to get working on RHEL 2.1 and the like, I 
wont consider the build-time optionality a hard requirement for inclusion, 
we can work it out eventually :) BTW I actually have plans to at least 
experiment with sqlite cache for package data for repomd repositories to 
see if it'd help with the ridiculously high memory use + slowness for 
repomd repositories, I'm not objecting to use of sqlite as such.

I should have time to have a closer look and take it for a test ride this 
evening, I'll comment more thoroughly then.

 	- Panu -








More information about the Apt-Rpm mailing list