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

[Frank Griffin]

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 ?