Bug#214610: wishlist - rollback capability for dpkg.
Andy Baxter <andy@earthsong.free-online.co.uk> writes:
> 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.
You can add roolback support by using LVM snapshots.
> 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.
You can also use snapshot.debian.net together with pining to revert a
system to a previous dates versions.
> 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:
Usually that works.
> - 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.
To hard to figure out usually.
> - 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.
Use LVM.
MfG
Goswin
Reply to: