[Mageia-dev] Proposed Feature:Backports_update_applet

Sat Jun 16 16:03:04 CEST 2012

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