[Mageia-dev] Proposed Feature:Backports_update_applet

Fri Jun 15 07:07:20 CEST 2012

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