[Mageia-dev] Proposed Feature:Backports_update_applet

[andre999]

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 fact it is a backport is ignored, then every backport would be, 
by definition, an update.  Even packages newly imported to Mageia.

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.

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.

-- 
André