On Mon, 10 Nov 2008, Callum Lerwick wrote:
On Mon, 2008-11-10 at 23:35 +0530, Rahul Sundaram wrote:
The real missing piece is 'undo' when you find out that a change in the
new version breaks something that you need. Does anyone know if that
actually works on systems using conary (i.e. can you back up a major
revision)?
Not feasible for RPM due to pre/post scripts. The rudimentary roll back
support in RPM has actually been removed in 4.6. It probably needs the
underlying filesytem to support snapshots. Something like btrfs needs to
be in place first.
We need rollback if we ever want to be serious about end-user testing.
With non-critical (as in, not needed for yum to run...) packages an "rpm
-e somepackage --nodeps" "yum install somepackage" offers something of a
rollback...
Filesystem rollback may work for full-distribution upgrade rollback, but
won't work so well for per-package rollback. A user should be able to
cherry pick updates to try from "updates-testing", and easily roll back
individual packages, or their entire system to "updates" or even the
"fedora" repo should something go wrong.
Debian can do this. The only reason we can not is because we refuse to.
The above use-case (perfectly valid use-case, mind you) is a very very
limited special case of rollback called "software downgrade". And that rpm
can handle just as well or badly as dpkg - it all depends on the software
in question, what its scriptlets do or don't do etc.
The question is, how would the package management toolchain be able to
differentiate "oops db4-4.7.21-4 from updates-testing crashes with a NULL
pointer thinko, gimme back db4-4.7.21-3 from stable repo" from "db4 update
from 4.5 to 4.6 broke things and testing it converted my db to 4.6 format
so downgrading back to 4.5 wouldn't do any good" and act intelligently in
both cases? One heuristic would be allowing downgrade between different
releases of the same version more freely but scriptlets can do damage even
in release bumps.. thats no solution either.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
