[Mageia-dev] Proposal: Updating released versions (long post)

Fri Oct 8 20:01:32 CEST 2010

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
+