OT yum rollback (was When will Fedora work again?)

[David L]

On Thu, Mar 12, 2009 at 8:37 AM, Seth Vidal wrote:
>
>
> On Thu, 12 Mar 2009, David L wrote:
>
>> On Tue, Mar 10, 2009 at 8:38 AM, Patrick O'Callaghan wrote:
>>>
>>> On Tue, 2009-03-10 at 11:01 +0000, Frank Murphy (Frankly3D) wrote:
>>
>> <snip>
>>>>
>>>> Then would it be time for some sort of "rollback" utility,
>>>> so if "yum update something" breaks, maybe  : yum --rollback something
>>>
>>> That's been discussed before. It's fantastically hard to do, short of
>>> snapshotting the whole system.
>>>
>>>
>>
>> I saw this article that seems relevant to this discussion
>> a few months back:
>>
>> http://www.linux.com/feature/155922
>>
>> It talks about a "next generation" package manager called
>> Nix that claims to solve this kind of problem I think:
>>
>> http://nixos.org/
>>
>> Whether nix is for real or not, from a naive user's
>> perspective it sure seems like it should be possible
>> to solve this problem.  It basically seems like what svn
>> or other version control systems already do.  They
>> remember changes (and for the case of text files,
>> they store only differences.  For binaries it should
>> also be possible to efficiently store changes... in
>> fact I seem to remember a new update feature that
>> will do something like that).
>
> binaries are only half of the problem.
>
> You also have to worry about rolling back the users data.
>
> if I upgrade from mysql4 to mysql5, for example and get mysql5 running then
> my databases have been converted. Now, if I rollback the binaries, how do I
> go back?
>
> Mysql is obviously a big item and maybe not that common so let's look at a
> more common one:
> firefox
> evolution
>
> these two seem to routinely change their config formats in incompatible
> ways.
>
> How does a rollback solve that problem?

Good point... like I said, I'm sure there are lot's of
devils in the details.  But for many of us on this list,
we already have that problem.  We boot to rawhide,
then we boot back into the latest stable release.
I do this on a weekly basis.  And as you mentioned,
I do experience problems with firefox and evolution
(but evolution gives me so many problems to begin
with that I barely notice).  But these problems are
minor inconveniences compared to the "oh $@#$,
I just updated and now critical feature XYZ is broken".
Now, you might respond with "how often does an
update break something critical?".  And the answer
is -  frequently in rawhide, and rarely, but sometimes,
in stable releases.  But the point is, you would only
experience the rollback user data inconveniences
when you're rolling back to fix something more
important.  Frankly, half of the rollbacks I would have
done historically would have been to revert to an
older version of evolution because the new one
was broken.  So the evolution user data argument
doesn't really work for me.  I admit that I did mess
up my firefox profile last week in rawhide and had
to create a new profile when I booted back to f10.

I would personally be happy with a rollback solution
that identified downgrade-hostile packages like
evolution and firefox and warned you that things might
break.  At least I would have a choice when an
update breaks things.  I would also be better able
to tell if an update broke something in rawhide instead
of wondering "did that really work before I updated,
or am I just senile?"

Cheers....

                David