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

Tue Jun 12 13:00:39 CEST 2012

blind Pete a écrit :
+> andre999 wrote:
+>
+>    
+>> 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.
+>>      
+> By definition you are completely correct, but I was deliberatly
+> bending the definition to cover beta software.  Or at least to
+> draw a distinction between an Extended Support Release package
+> and a standard package.  A new name would make sense here.
+
+They would have different names (if generally only the version included 
+in one).
+Since a backport can only have one name, it would correspond to only one 
+of the packages.  Presumably that with the same (or closest) version.
+
+>> 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.
+>>      
+> [snip]
+>
+> Some packages annoyingly have two current versions.  When that
+> happens it seems perfectly reasonable to just pick one, but if
+> anyone is ambitious enough to try two at once, this would be a
+> mechanism to handle it.
+
+Don't see how backport repos are related.
+To be installed simultaneously, they would have to install to different 
+locations, which is generally not the case.  There is more than one 
+version of Postgresql available, for example, but they conflict and so 
+can't be installed at the same time.
+
+-- 
+André
+
+