Le vendredi 08 octobre 2010 à 09:36 +0200, Luca Berra a écrit : > On Thu, Oct 07, 2010 at 07:49:29PM -0400, Frank Griffin wrote: > > > >(Here's the biggie :-) ) > >4) We need to enhance the urpmi.recover functionality and bring it fully > >into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS > >PREVIOUS VERSION (sorry for the caps). If we don't want to be stuck > I just read it 3 times, and i still believe doing the above might prove to be > a > nightmare. > rolling back a single, well identified change is a doable task. > rolling back proceduraly a complex change becomes exponentially complex > even for experienced system engineers, let alone a piece of software.
We could, using brtfs/lvm snapshots. But this may produce some hidden side effects. Maybe we could do the reverse : ie, we do a clone / snapshot for testing the upgrade ( maybe in a vm, except a vm would not help to test real hardware issue ), and if people are not satisfied , they do not put it in "production". I think there was a presentation about rpm rollback at FOSDEM this year ( or last year, maybe ), but I didn't really listened, as I do not remember how it ended. -- Michael Scherer
