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

Re: And now for something completely different... etch!

* Petter Reinholdtsen <pere@hungry.com> [050607 16:00]:
> You should be careful when using your imagination as the guideline for
> what is useful or not.  It might not be a very accurate source of
> information.
> RPM got rollback support, and it is very useful.  I recommend reading
> some of the articles describing its support.  For example
> <URL:http://www.linuxjournal.com/article/7034> can be used to learn
> more about this feature.
> I wished dpkg supported a similar feature.

When I understand this correctly, this is more of a feature for apt or
even some higher level tool, to make sure you can those packages again
or repack them.

But the problem is that for this to work this way, you have to support
downgrades. With a more complex scheme supporting redowngrades (i.e.
upgrading and downgrading again when no user-made changes were done)
would be needed.
This has to be supported on a per package level in order to work. Many
packages are boring enough a normal downgrade will work, but there are
enough cases like databases to be converted to a new format or even
only some reodering of some symlinks, that are not trivially revertable.
(As changes do not need to be really injective, it might even be
 theoreticaly impossible to do a downgrade). Supporting redowngrading
might be easier, as only all changed files have to be saved somehow
and be reapplied in a correct way.

But it currently is already hard to make sure upgrading works correctly
and with all older versions that can realistically be supported.
Testing and thinking of all those things needed to (re)downgrade is
even harder. Especially if one also wants to support rolling back
because some total-system-upgrade from one distribution to another has
to be supported. (If we knew all possibilities such a thing could break,
we would already cause it not to break upgrading, so how can this
realistically been tested?).

Which in my eyes yields to the reason this is not and most likely will
not be implemented: If you need the ability to fast roll-back upgrades, 
you need to make an backup of everything poosibly changed (which easily 
means a full backup), because noone will be so insane to guarantee you
it will work otherwise, no matter how much labor is but in there.
And if you have to do such a backup anyway, why put work in other
mechanisms, when the backup already supports a full, secure roll-back?

  Bernhard R. Link

Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Reply to: