David L a écrit : > 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). > > David > It used to exist but was removed in the recent rpm version because nobody was maintening it and there was some problems (see below for example) I still think it would be useful to have because when you start from point a which is working, apply an update which break some functionality , you wan't to be able to roolback to an kwown point. It is also important to have a rollback process working so you can be more confident about apply updates in a production environment. you can for example use this on a redhat enterprise 4.(search for rpm rollback on internet and you will find pointers as there are no real docs) We've been testing this in a corporate environment and it was rather buggy. We have falled back to manually reinstall a old rpm if there's a problem when going into production, which is very rare for rhel (rollback would be very useful for rawhide !) For example, you install your system. you activate rollback. you set a max rollback point (to avoid uninstalling the system) At a later time, you wan't to update your system you update it. the process create on the fly "rollback rpms" so far seems ok. but... you test it you ask for rollback and in the middle of the rollback, somme rollback rpm breaks and the system stops in an unmaintenable state.... in our case, ssh was uninstalled during the update and during the gcc unistall, a gcc rpm script executed, depending on another package, which was being downgraded and was missing at the time the script ran... we had to reinstall all the missing rpm one by one until the system became reusable.... the second big problem is that as not a lot of people use this, there are missing unistall dependencies, which lead to this kind of problem. I'm not desesperate about seing this resurect one day in a supported redhat enterprise way but that's not an easy stuff Mat -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
