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

[Lyos Gemini Norezel]

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, 

Someone who understands the code should be able to verify the claims...
the source is here:

svn checkout https://svn.nixos.org/repos/nix/


>> 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...

Doesn't diff already do this (for binaries)?

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

Rollback the whole of mysql? or just the databases?
If the rollback is for the whole of mysql it *should* rollback the db's 
as well...
if changes are stored by diff (or similar method) the rollback shouldn't 
be too difficult.

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

Seems to me that this should/would be considered part of the existing 
program...
if you rollback one... you have to rollback both.

If a diff (or similar) is stored for the configs/data/etc... the 
rollback wouldn't be much of an issue.

The problems I can see...
a.) new data on upgraded program... how to rollback?
          1.) the answer to this is painful... but fairly obvious in my 
opinion...
                warn the users that any new data stored since the 
upgrade will be lost.
b.) config changes on upgraded program?
          1.) answer same as above.

This feature would be fine for advanced users who understand the 
danger... but for novices
this is equivalent to placing a .45 cal in a child's hands.
On the other hand... linux has done such for years... why worry now?



> -sv


Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20090312/857677e6/attachment.vcf>