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

[blind Pete]

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