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 ?