[Mageia-dev] Proposed Feature:Backports_update_applet

[blind Pete]

andre999 wrote:

> blind Pete a écrit :
>> andre999 wrote:
>>
>>    
>>> blind Pete a écrit :
>>>      
>>>> andre999 wrote:
>>>>
>>>>
>>>>        
>>>>> blind Pete a écrit :
>>>>>
>>>>>          
>>>>>> Samuel Verschelde wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>      
>> [snip]
>>    
>>>>> - 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.
>>>>
>>>>        
>>> I was thinking of cases where the user chooses to "update" their
>>> system.  New versions of backports already installed would be presented
>>> as updates, along with those from the update repos.
>>> Just as we don't have any update-update repos, it wouldn't make sense to
>>> have backport-update repos either.
>>>      
>> [snip]
>>
>> It depends on how you look at it.
>>
>> If you consider non-free, tainted, and backport to be optional
>> and any update package to be highly recommended if and only if
>> the corresponding package is already installed.  Then is does
>> not matter if the old package is a tainted.rpm, nonfree.rpm,
>> bp.rpm, or an ordinary rpm.  Just one way to look at it, not
>> the only way.
>>
>>    
> But how is it possible to distinguish a priori between a backport which
> will be an update and one which will be a "new" backport on a users'
> system.  It would only be an "update" if the user has already installed
> the corresponding backport on their system.

If the rpm is tagged, either internally or just by having "bp" in 
the file name you can tell if it is a backport.  If a new package 
has the same name - including the "bp" part - but a higher version 
number, install it, else, just list it as available.  Or they could 
be kept in different places.  

> If the fact it is a backport is ignored, then every backport would be,
> by definition, an update.  Even packages newly imported to Mageia.

???  

I meant that the logic for dealing with a bp-update would be the 
same as for nonfree-update and tainted-update (and I suspect, 
update itself).  Re-use existing code.  

> To me, a "corresponding" package is one from the same category,
> according to whether is is backport or not, and according to whether in
> "core", "nonfree", or "tainted".
> To consider otherwise is to deny the importance of these categories.

Catagories multiply here, not add, you have listed six, not four.  

> Backports are considered separately because they are much more at risk
> to not function properly, since they weren't tested with the rest of the
> release, being added afterwards.  So we have to be much more careful
> about adding them.  The last thing we want is for the backports to be
> included automatically with updates, even if the user had not already
> decided to install the corresponding backport.  Installing a backport
> should be an exceptional, explicitly decided activity -- except when the
> user has already decided to install the corresponding backport, when it
> is useful to present newer versions as updates.  They are likely
> security or bug fixes.

I think that we are in agreement.