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