[Mageia-dev] Proposed Feature:Backports_update_applet

blind Pete 0123peter at gmail.com
Tue Jun 12 07:36:27 CEST 2012

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" 

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