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

Sun Jun 17 08:27:34 CEST 2012

andre999 wrote:
+
+> 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.
+
+Not installed simultaneously, but exist simultaneously.  
+Firefox and Chromium-browser are the bad examples that spring to mind.  
+
+$urpmq -Y chromium-browser- | sort | uniq
+chromium-browser
+chromium-browser-beta
+chromium-browser-stable
+chromium-browser-unstable
+$urpmq -ia chromium-browser- | grep Version | sort | uniq
+    $MIRRORLIST: media/core/updates/media_info/20120610-144059-info.xml.lzma
+Version     : 12.0.742.53
+Version     : 13.0.761.0
+Version     : 18.0.1025.168
+$
+
+-- 
+blind Pete
+Sig goes here...  
+
+