[Mageia-dev] Proposed Feature:Backports_update_applet

andre999 andre999mga at laposte.net
Sat Jun 9 22:53:39 CEST 2012

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 :)
- 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.

- 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.

- Functioning as an update, it would only replace already installed 
backports, once the tools are appropriately adjusted.

- 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.)


More information about the Mageia-dev mailing list