Debian Bug report logs - #214610
wishlist - rollback capability for dpkg.

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Andy Baxter <andy@earthsong.free-online.co.uk>

To: submit@bugs.debian.org

Subject: wishlist - rollback capability for dpkg.

Date: Tue, 7 Oct 2003 18:09:57 +0100

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.

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Andy Baxter <andy@earthsong.free-online.co.uk>

Cc: 214610@bugs.debian.org, submit@bugs.debian.org

Subject: Re: Bug#214610: wishlist - rollback capability for dpkg.

Date: 07 Oct 2003 20:02:46 +0200

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

Message #15 received at 214610@bugs.debian.org (full text, mbox, reply):

From: Andrew Suffield <asuffield@debian.org>

To: Andy Baxter <andy@earthsong.free-online.co.uk>, 214610@bugs.debian.org

Subject: Re: Bug#214610: wishlist - rollback capability for dpkg.

Date: Tue, 7 Oct 2003 20:05:57 +0100

[Message part 1 (text/plain, inline)]

On Tue, Oct 07, 2003 at 06:09:57PM +0100, Andy Baxter wrote:
> - 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.

This would require vast amounts of manpower. It's not going to
happen. Debian does not support downgrades, and will not anytime
soon.

> - 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.

This is an approximation of the correct solution. The common name for
it is a "backup" system (you've added delta compression, but that's
not necessary). There are many packages providing backup solutions in
Debian. I suggest you use one of them.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.