My roadmap for a better Fedora

[Jeff Spaleta]

2008/11/19 Callum Lerwick <seg at 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."
>
> 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?

>
> 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'?

rpm -qa --qf "%{NAME}:\n %{TRIGGERSCRIPTS}\n"

If for example the conditions are met which fire off hal's triggered
scripts... if you rolled back hal across that condition
boundary..would things get reverted? That's probably not relevant for
current, expected, update needs. But until we test all triggers for
rollbacks we don't know where we stand.

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?

> First, could you please do something for me. Forget implementation.
> Forget the details. Just answer this simple yes or no question:

>
> Is rollback a desireable feature?

That's a horrible pointless question.  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. What packaging
mechanisms are we willing to give up in order to make rollback at the
individual package level easier to achieve?  I honestly don't think
there is a single mechanism that we are willing to give up.  So if
rollback is going to be a compatible its going to take a much more
clever monkey than myself to figure out the "details" which work.


> I never said I have all the answers. I can't do this alone. "Many eyes
> makes all engineering challenges shallow"

I'm pointing out known complications to the problem.  I suggest you
read up on Carrier Grade Linux which I think attempts to makes
rollback an important specification deliverable..but my knowledge is
somewhat dated.  If there is a group that has thought hard about
rollback...its them. Whether or not what they've come up with is at
all applicable is another question entirely.

-jef