[Mageia-dev] Backports policy clarification (and discussion)

Sat Jun 9 12:04:41 CEST 2012

blind Pete a écrit :
+> Samuel Verschelde wrote:
+>
+>    
+>> Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit :
+>>      
+>>> On Fri, 08 Jun 2012 10:22:41 -0400, Samuel Verschelde
+>>> <stormi at laposte.net>
+>>>        
+>> wrote:
+>>      
+>>>> I think you missed my point. If Mageia 1 "backports" has higher
+>>>> versions than Mageia 2 "release" (not backports), upgrade can fail
+>>>> because currently our tools do not take backports from the target
+>>>> release (mageia 2) into account when upgrading a distro.
+>>>>          
+>>> In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear, that
+>>> upgrading from a system with 2010.2 Backports was not supported.  It may
+>>> work, but was not recommended.
+>>>
+>>> I think we should keep the same policy for the upgrade from Mageia 1 to
+>>> 2.
+>>> I.E.  Don't use backports if you are planning on later doing an upgrade,
+>>> rather then a clean install.
+>>>
+>>> That way, Mageia 1 users who want firefox 13 can get it, without us
+>>> having to replace the Mageia 2 iso images with an upgraded installer,
+>>> that will keep backports enabled for 2, if it was enabled for 1.
+>>>        
+
+Current tools will correctly update backports much of the time.  (From 
+my experience.)
+The tools just need to be reworked somewhat to ensure that backports are 
+updated correctly all of the time.
+
+>>> Regards, Dave Hodgins
+>>>        
+>> Again, this is not the policy we adopted. When we defined the backports
+>> policy (together, although it seems most people are just discovering it
+>> now) we said that we didn't want to have backports that don't work, break
+>> a system, or prevent upgrade.
+>>
+>> However, I think that for DVD upgrade without internet access this is a
+>> sensible option. But the upgrader should detect the situation itself, not
+>> hope that the user will read somewhere in the release notes that it's not
+>> supported.
+>>      
+> No, just include Cauldron's backport repositories (disabled by default)
+> inside the DVD iso.  Upgrade to the release version, if possible.
+> If that is not possible, upgrade to the version in backports.
+
+Cauldron's backport repos will always be empty.
+If you introduce a new package, or a new version of an existing package 
+to Cauldron, it is not, by definition, a backport.  Even though the same 
+version (not counting the revision) may be a backport for previous releases.
+
+So if we do a release update to the latest release, backports will be 
+replaced by regular packages except in those cases where a newer version 
+has been introduced into Cauldron.  And if we update to Cauldron, all 
+backports will be replaced by regular packages -- according to our 
+backport policy.
+
+>> And there should be a way for those who have internet access to upgrade
+>> online *with* backports too.
+>>      
+
+True, to allow the user to do the release upgrade in one step.
+>> Samuel
+>>      
+
+Effectively during release updates, we have to treat backports as 
+updates to installed backports.
+Because dependancies may differ between releases for the backport, 
+installed backports will always have to be updated.
+However many users are in a situation where they cannot do online 
+updates when installing a release update,  (That is my situation.)  So 
+they have to do updates as a separate step.
+This means that in would be prudent to always treat backports as updates 
+to installed backports, even if not doing a release update.
+If all backports packages are tagged as backports (in the file name), it 
+will be relatively easy for the tools to recognize and appropriately 
+treat backports.
+
+We have to avoid backports of packages that could make the system 
+unbootable, or the major desktops unstartable, but note that this is 
+already more than covered in the backport policy, under "packages scope".
+
+In sum, as long as our tools can clearly identify backports, it should 
+be easy to adapt them to properly treat backports.
+So I think the policy should be changed to always tag backports in the 
+revision part of the file name to facilitate recognition of backports, 
+such as is usually done for "tainted" packages, and sometimes for "nonfree"
+
+Maybe to facilitate keeping backports up to date, we should ensure that 
+rpmdrake (and the other tools) include backports in the security and 
+bugfix options.  This may already be the case.  (While still treating 
+them as backports.)
+
+-- 
+André
+
+