On Wed, 2008-11-19 at 11:46 -0900, Jeff Spaleta wrote: > 2008/11/19 Callum Lerwick <seg 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...
Description: This is a digitally signed message part