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

James Olin Oden james.oden at gmail.com
Tue Feb 26 15:39:28 UTC 2008

>  > Based on the above I'd say there's clearly a demand for urpmi.recover ,
>  > and a non-zero quantity of people using it right now.
>  I don't disagree at all. I just think that the vast majority of the users
>  actually just want rollback/recover as in downgrade to previous version
>  when the latest upgrade broke something, essentially rpm -Uvh
>  --oldpackage <previous version>. Of course the old package needs
>  to be somewhere available for you to be able to do that, but instead of
>  rpm creating packages with busted up contents, you could use the upper
>  level depsolver to cache all downloads (no more diskspace wasted than with
>  --repackage) and downgrade at request.

Well until a new package does something heinous or irreversible to a
config file.  The really do want the original configs put back, they
just don't know it.   I rememberin the solaris days their was an
upgrade to Sendmail that totally zapped your sendmail.cf...course that
was going forward, but the idea is the same.

People, intuitively expect things to be back they way they were after
a rollback, even if they can't define all the details of what that
actually means.
Or put another way, they expect things to work like they used
too...thats a very real requirement, even if it is a tad subjective.
But then I can't remember the last time I argued with a customer about
their expectations being too subjective.

>  I think practically all depsolvers offer the caching option already, any
>  many if not all support downgrading too. What's missing is version history
>  information, ie "revert selected/all packages to whatever versions they
>  had yesterday because todays update broke stuff", rpmdb only stores the
>  installation date, not version history.
The version history, though not kept in a straight forward way that us
humans can understand, was retrievable via walking backwards through
installtids in the db and removetids in the repackaged packages.  If
it were me I would have done things completely differently by actually
having a straightforward no questions about it transaction history.
That said, there is something to be gained by having some of that
history in the packages themselves (durability), but still, I would do
both, and then use one to audit the other.  After I fixed them, Jeff's
forward links and backward links you'll find in the later Johnsonian
versions of rpm actually do this (i.e. add more durability, but not
ease of understanding).


More information about the Rpm-maint mailing list