[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [APT] rollback functionality for apt

Hi Michael and all,

I'm colleague of Joao and here are my 2 cents. :-))

> One problem with it is that the deb package maintainer scripts
> (postinst/preinst/postrm/prerm etc) can modify anything one the system
> (my understanding is that this is the case for rpm scripts as
> well). 
The same with RPM, indeed.

> So in the general case a rollback would have to take a snapshot
> of the system as e.g. a package could rewrite /etc/fstab to support
> mount-by-UUID or a package could convert its (internal) database to a
> new format during the upgrade. From my understanding of the patch, a
> rollback would install the old packages that can't read the updated
> database format and the application would no longer work. This is
> certainly a corner case, but it seems to be happening often enough to
> be a real concern.
> This is probably something that needs to be adressed by policy and not
> by technical means. So I would be interessted if this is a issue on
> rpm based systems too and/or if there is a policy that helps
> preventing the problem there.
May be the two cases you pointed out are somehow different.

In the first case (changing a external file - the fstab - in the
pre/install) should already - by policy - be reverted in the un-install
script (at least ww do so in our CM RPMs). For instance, changing the
mount-by-UUID should be changed by the un-install script...
In fact, it seems to me that the problem you mentioned already happens:
if you want to uninstall a .DEB that changed files outside the DEB
package, things are not reverted unless un-install prevents it.

In the second case, the update for a new DB format, is more difficult to
revert and most of the times are not addressed in un-install scripts.
In that case, what we might call "non-returnable critical operations" in
scripts, a rollback of a upgrade (which is in fact a downgrade) not only
create a problem but it would not warn the user. Nevertheless, the user
could always get back to newer version.

Changes of the file system by a install script may then fall in one of
the categories:
   - change of a conf file (may be 70% / 80% of all changes): dealt by
apt rollback feature
   - change of file that could be reverted by un-install scripts (may be
15% / 20%): dealt by un-install script
   -  not-returnable change in a file (may be 15% / 20%): dealt by user
through backups

Is not that 15% is to despise, but today package policies (RPM, but
seems to me that DEb too) tends to minimize it:
    - Should be avoided change files outside deb in the
pre/post/install/uninstall scripts
    - If the previous point could not be avoided, un-install should
revert it

Finally, it seems that what is more important is apt-get rollback
feature will not create a new problem.
The problem is already there and happens to users that do it by hand and
without a support of apt.


| Director Técnico
| Caixa Mágica 
|             - Energia Open Source
| http://www.caixamagica.pt         

Reply to: