[Mageia-dev] Proposed Feature:Backports_update_applet

[andre999]

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

-- 
André