Bug#214610: wishlist - rollback capability for dpkg.
Package: dpkg
Version: 1.10.10
hello,
Have you considered bringing in some kind of 'rollback' capability for
dpkg and the apt package management system? I'm asking because one of
the things that has put me off debian and caused me frustration in
using it is the problem that the current stable version can get quite
out of date (e.g. no kde3, which is over a year old), but running
unstable sometimes causes packages to break (e.g. I just moved to
unstable, and now kmail isn't working), and fixing problems like this
needs a fair degree of skill, and is frustrating even for people who do
know what they're doing. This is also one of the things which makes me
cautious about recommending debian to non-geeky friends.
Something that would help in this is if there was some way to record
the history of the state of the package management system, and let the
user rollback the system to a previous saved state if something goes
wrong with an upgrade. This way, it would be possible to run a system
mainly from testing or stable, and only upgrade the packages you
actually need to unstable or testing, without having to worry so much
that you might break your system doing this.
I can see that this might be difficult to implement, as the package
installation scripts are only designed to cope with upgrading from
previous versions, not downgrading from later versions. I can see a
couple of possible ways round this though:
- add an extra item to the package information which gives the version
number of the earliest previous version you can safely downgrade to by
running the installed package's remove script followed by the earlier
version's install script. This would probably allow most packages to
downgrade ok, but still give some way of stopping the system breaking
even worse when incompatible changes have been brought in. (e.g. when a
package has been split or renamed). I don't know the package management
system well enough to know if this would be the best way, but some
system like this where the information on how to safely downgrade is
put into the new package rather than the old one which nobody is going
to have the time to re-write, might work.
- alternatively, cache all script-based changes (i.e. those which
involve more than just loading a file from a package) to the system
into some kind of diff archive whenever you upgrade. This is probably
not the best way as it would get unwieldy for a history longer than
maybe half a dozen changes, but it might work as a stop-gap measure to
allow some degree of downgrading where the user notices the problem
fairly quickly. This method would also have the problem that the
rollback could only go back along the previous path, whereas the
previous method would give a generalised safe method of downgrading
packages in whatever way the user wants.
andy baxter.
Reply to: