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.
Cheers.
--
_____________________________________
| Director Técnico
| Caixa Mágica
| - Energia Open Source
| http://www.caixamagica.pt
Reply to: