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

Fri Oct 8 01:49:29 CEST 2010

Part of the recent thread about what the desirable release cycle should
+be devolved into a discussion of how backports works and whether or not
+it's suitable.  I'd like to examine this issue.
+
+The current urpmi repository architecture serves purposes that were
+meaningful to Mandriva.  It segregates main from contrib for statement
+of support reasons, it separates non-free from main for philosophical
+reasons, and it separates restricted from main for legal and business
+reasons. 
+
+This works pretty well for cooker, where you either want a particular
+category of package considered or you don't, but the reuse of this model
+for updates, backports, and testing in released versions isn't as good a
+fit.
+
+The root of the problem is that the user base is different.  Users of
+cooker want the latest and greatest of everything, and have accepted
+that if something breaks in cooker, it may stay broken for awhile. 
+Users of released versions vary all over the map, from people who never
+want anything to change to people who want some specific updates to
+people who want everything new but want it stable.  Users of cooker
+rarely think about security updates, because in grabbing everything
+available constantly, the security updates are "just there".  With users
+of released versions, they may have to opt-in for security updates, and
+usually want to treat other updates differently.
+
+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
+won't.  Instead, let urpmi or rpmdrake have knowledge about all
+repositories whether enabled or not, and display the offerings with an
+icon, tooltip, or extra column that indicates the status of the package.
+
+2) The update tool we give these users should distinguish between
+security updates and backports/testing, but present them both.  This is
+very much like the Windows Update model, where all available fixes are
+divided into "Critical System Updates" and "Software Updates".  We don't
+really have the same support constraints as Mandriva, and there's no
+need to automatically disable backports across the board, and not even
+present the backports as possibilities.
+
+3) Users should be able to enable options for each category
+independently.  Most users would probably want security updates applied
+automatically, but would want to be notified of availability of
+backports or testing and choose those manually.
+
+(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
+with trying to reconcile our desire to QA some packages better than
+others with some users' desires to at least *try* the newest stuff, then
+we need to allow them to move forwards and backwards in the package
+history as easily as possible.
+
+Yes, I know this is problematic.  It means that we have to do a really
+good job of getting dependencies right.  But if the dependencies *are*
+right, then this should be doable. 
+
+It means that we need to expand the logic in urpmi that can currently
+identify the packages that need to be uninstalled if some other package
+is uninstalled so that it can take into account the package it will be
+installing in its place (and the other older versions of packages that
+it will require), and compare the two lists to produce a "diff".
+
+It needs to decide which changes can be "quiet", e.g. "A" 1.3 requires
+"B" 1.3" and "A" 1.2 requires "B" 1.2, so a request to replace "A" 1.3
+with "A" 1.2 would cause a replacement of "B" 1.3 with "B" 1.2 in the
+same transaction.  This may have a cascading effect.  In any event, the
+user should be told what's going to be backlevelled, but specifically
+*not* see the current urpmi list of everything that will have to be
+removed if "A" 1.3 is removed if most of that stuff is simply going to
+be replaced with its own previous versions.  In other words, rather than
+tell the user that removing "A" 1.3 is going to remove half of KDE and
+scare the sh*t out of him, just tell him that the following packages are
+going to have to be backlevelled as well.  If there really are things
+that can't be undone and redone, that should be a separate highly
+visible prompt.
+
+This will require some extended transactional support in urpmi, I would
+think, because we'd literally have to overrule rpm about pulling stuff
+out from under the feet of other packages if we knew we were going to
+put it back.  That would mean that we'd have the responsibility of
+ensuring that the transaction either committed fully from our
+perspective, or got fully rolled back.
+
+This also means that packagers would have to be aware of packages that
+reformat their  application files as the version increases, and would
+have to archive previous versions using some naming scheme so that they
+could be restored (and the current version archived) if an uninstall was
+requested.  Of course, this would require a prompt to the user to inform
+him that any configuration changes made since the upgrade would be
+lost.  We'd probably also have to expand the "rpmnew" concept to be
+version-specific.
+
+Yes, I realize that a couple of clicks could require a *lot* of
+processing; but that can happen today, and the user would still get a
+prompt about what was going to be done.
+
+=========================
+
+If all this were done, updates/backports/testing could be touted as a
+"try it" environment.  Click on the update(s) you want to try, we'll
+tell you what else we're going to have to upgrade as well, and if for
+some reason it doesn't work, you click to restore it to version x.x, we
+tell you what will also be restored, and we do it.  That way, we don't
+have to worry about "guaranteeing" perfect quality updates.  If we
+missed something, and it doesn't work for you, just roll it back.
+
+This does require access to all previous versions of each package since
+release.  However, unless we screw up royally on a recurring basis, the
+demand for these intermediate packages should be *much* lighter than for
+the current versions, so hosting them on a Mageia primary or possibly
+the first-tier mirrors should be sufficient.
+
+It may be that a good implementation of this would require the
+availability of significant disk space for translation-related backups
+or such, on the root partition or some other designated partition.  If
+so, we should determine if there is sufficient space, and if not, alert
+the user that his choices are to abort the update or else realize that
+he won't be able to roll back.  Windows XP SPs do this.  I don't see a
+problem with this, since the current urpmi response to insufficient disk
+space is basically to abort the package install but keep going.
+
+Thoughts ?
+