andre999 wrote: > blind Pete a écrit : >> Samuel Verschelde wrote: >> >> >>> Following Backports opening due soon, and since our policy is that >>> backports are supported (security, bugfix), we need a way to push >>> backport updates for users who installed backports. Otherwise, we can't >>> really say that we're providing security updates to our backports. >>> >>> My feature proposal is to implement something similar to what mgaonline >>> + MageiaUpdate does for updates, but for backports, with some changes >>> due to the fact that users will rarely want that "all" packages on the >>> system be updated from backports when the backports media are activated. >>> >>> https://wiki.mageia.org/en/Feature:Backports_update_applet >>> >>> I don't think I can do the dev myself. I can work on more detailed >>> specifications with a developer though. >>> >>> Samuel >>> >> There are a multiple ways that this problem could be handled. >> Yours is one. >> >> Samuel's way: >> >> Need "something" to know that a backport package >> has been installed, to remember that fact, and to do an extra >> backport update search when looking for updates. >> >> It would need to keep working if the user changed desktop >> environments, or even stopped used a desktop and just used >> the command line. Does mgaonline do this? There could be >> room to improve that. >> >> If it can be detected that a backport package has been installed >> (or less efficiently, detect that a backports repository >> has been activated) set up a cron job (or reconfigure mgaonline) >> and leave it like that for the life of the installation. >> >> Geeks way: >> >> Only use urpmi as a command line tool and edit urpmi.cfg with vi. >> >> When activating a backports repository mark it as an update >> repository. Then update with "urpmi --excludemedia [backport media, >> ...]" accepting all suggestions, followed by "urpmi --auto-select" >> and look at what is offered before accepting. >> >> My suggestion: >> >> Add "bp" to the package name and have separate backports update >> repositories. >> >> Users would then be able to cherry pick from backports and >> updates should _just work_ without extra intervention. >> >> The only difficulty that I can think of is, when a backport >> (or backport update) package is pushed to updates. It would >> not be necessary to do a real update but the rpm database >> should be updated such that version N-bp supersedes version N. >> (And the N-bp packages should be removed from the repositories.) >> >> Can anyone see any holes in the logic? >> >> What would be easiest to implement? >> >> > You got me thinking :)
Thinking is always dangerous. ;-) > - Just marking all backport repos as update repos is almost enough to > solve the problem, in terms of the tools installing the backports. > Great idea ! > We just have to tweak the tools so that a backport is only installed as > an update of a backport. Because the contents of the backport repositories changes during the life of an installation it is desirable to... well... um... "update" the database about that. > - Note that we should allow a non-backport to replace a backport, as > will likely be encountered in a release update. If the versioning is > properly done (according to established packaging policy), a > non-backport in a newer release will have a higher version number, thus > replacing the backport. If they had the same version number you would not want to do a real update, but you might want to adjust the database. I have no idea if that would be more trouble than it is worth. > - Functioning as an update, it would only replace already installed > backports, once the tools are appropriately adjusted. There are a couple of ways to do that. The simplest that I can think of is to split "backports" into "backports" and "backports update". Allow cherry picking from "backports" and apply "backports update" automatically. > - As with any update repo, one could always explicitly install a > backport which is not already installed. No special treatment is > required for this. > > - using "bp" in the file name is nice and short, and definitively marks > it as a backport for the tools, and for the user once installed. (I > would put it in the revision field.) > I like this approach, as it doesn't matter from where the package is > installed; it will always be recognized as a backport. > > So I'm suggesting a variation of the last 2 solutions. > I think that this would be relatively easy to implement. > The trick is to find the right place in the code for the tweaks. > (tv could probably do it really fast.) >
