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

[Marc Paré]

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