Luca Berra wrote: > On Thu, Oct 07, 2010 at 07:49:29PM -0400, Frank Griffin wrote: >> I'd like to propose the following model for updating released versions: >> >> 1) Users should not have to see, except in minor ways, the different >> repositories. Urpmi may see them, and advanced or ideologically polar >> users may care about them (e.g. free vs non-free), but most users > I object to this specific point, if what we are doing is free software > that should be made clear to users. and i believe the user shold be > asked wether they want to use only free software or not.
I have no objection to allowing users to check a box saying they want free or mixed systems. I just don't want them to have to mess with a repository to do it. > 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. I agree that the work becomes exponentially complex, but not the concept of what has to be done. After all, what can be installed in an automated way can be uninstalled. In any case, I would think that the primary use of this facility would be to uninstall a single package. Urpme already knows how to do that, and (provided you have the older RPM around) urpmi knows how to install the old one. We expect users who want to roll back a package to do that manually today. The problem is that removing the new package, if it provides something that lots of things require, will want to uninstall a large number of packages uselessly, because it doesn't know that you're about to turn around and install something else that provides it. All I'm suggesting is that (a) we make the older RPMs available somewhere (b) we automate the process to save three manual steps, and (c) we wrap them in an atomic transaction (or what looks like one to the user) to solve the problem above