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

Fri Oct 8 03:29:59 CEST 2010

Le 2010-10-07 19:49, Frank Griffin a écrit :
+> 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 ?
+>
+
+Hi FranK:
+
+As it seems we keep going in circles on this Romain has arranged the 
+following so that the threads on this topic become more focussed:
+
+--------------
+
+It has been posted before but I guess it's a good read for anyone
+willing to push an argument in this debate:
+http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/
+
+It is a nice post explaining the existing different point of views
+(bonus to clever points about updates frequency and presentation).
+
+Now, in the same vein, let's put the discussion at rest a little and
+have each interested person write down an article with arguments for
+the why's and how's. So here is a page for that:
+http://mageia.org/wiki/doku.php?id=rollingdebate
+
+Please write down your point of view, detail it as explained on the
+wiki page, link it and a week from now, everyone involved in the
+discussion can have a look at it for a summary.
+
+That won't trigger a change decision at once (way too soon anyway, we
+have to roll a first release to assess our new build system and
+infrastructure and organisation) but it may at least lay down all
+arguments and allow to have a better view of what everyone understand,
+agree on definitions and see what is really at stake here. For later
+reference, discussion and decision.
+
+Thanks a lot.
+
+Cheers,
+
+Romain
+
+--------------
+
+Marc
+
+
+