On Wed, 2008-11-19 at 11:46 -0900, Jeff Spaleta wrote:
2008/11/19 Callum Lerwick <seg(a)haxxed.com>:
> There are many options here.
>
> 1) Ban everything that breaks rollbacks. Find some other way to do it.
these features were implemented for a reason. You grossly oversimplify
the problem by saying "find some other way to do it."
And I think you're making things out to more complex than necessary.
> 2) Just refuse to rollback the packages that break rollback.
How do you know they will break roll back? How do you test rollback in
an organized way?
With automated regression tests.
>
> 3) A combination of both
>
> This is an example of where we need specific examples of scripts and
> such that break rollback to get any farther on this.
Since noone tests for rollback there are no obvious examples of known
rollback breakage. We don't look..we don't test... so we don't know
what currently breaks. You'd have to take each special case...and
attempt to trigger the condition and test for differences. But since
we are talking about scripted actions which could literally do pretty
much anything...how do you set up a test which attempts to measure
whether rollback across a trigger boundary put you back to where you
were? How much of a different in state counts as 'break rollback'?
Well then we start testing...
Make up a copy-on-write VM image containing a stock Fedora release,
upgrade it with all current updates, then roll it all back. Diff the
filesystems before and after. Analyse the differences. Do this test
between release and updates-testing, updates and updates-testing, etc...
This will quickly give us a pretty good idea of the true extent of the
problem. Of course, this requires developing a rollback mechanism to
test in the first place...
If this ever goes anywhere, we could have an automated system to test
rollback of all updates before they even get pushed in to
updates-testing.
Also note my reply to Ralf, I do not expect this mechanism to work
across releases.
And then there are obsoletes. How many new obsoletes do we introduce
in updates? Any idea? a run of repoquery against the f9 release and f9
updates tree would be able to tell us that. When an obsolete is
introduced in an update... can we rollback and get what we had?
Well presumably the rollback mechanism would have to keep some kind of
transaction journal anyway, log the obsoletes in the journal, and
reverse them upon rollback. "Undo" is not a new area of computer
science.
> Is rollback a desireable feature?
That's a horrible pointless question.
On the contrary, it gives me insight into your motivations. Going in to
technical detail is an unproductive sidetrack if you're not even
understanding why I think it's such a vital feature. Such a feature is
going to require a coordinated effort across the distribution, without
the unanimous support of FESCo and board members like you, the effort is
doomed to failure...
I posted my motivations here:
http://www.redhat.com/archives/fedora-devel-list/2008-November/msg01387.html
I don't know what more I can say than that...
There are many features which
are desirable..but not necessary easily compatible with each other.
Drop dead easy smooth upgrades are not necesssarily going to be
compatible with rollback. So the right question is.... is rollback
more desirable than other packaging features.
Well my argument here is the alternative is getting stuck with a broken
system. A broken system is as undesirable as it gets. A broken system
makes any other feature you can name a rather moot point...