[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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
begin:vcard
fn:Lyos Norezel
n:Norezel;Lyos
org:GBES, LLC
adr:;;;;Ohio;;United States
email;internet:Lyos GeminiNorezel gmail com
title:Computer Repair Technician
note;quoted-printable:"Those who hunt monsters beware, lest they become monsters themselves.Ify=
	ou stare long into the abyss, the abyss stares back into you." --Nietzsch=
	e=0D=0A=
	=0D=0A=
	Mundus Vult Decipi et Decipiatur -- Latin Proverb
version:2.1
end:vcard


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]