[Mageia-dev] Backports Summary

Wed Jun 27 19:46:22 CEST 2012

nicolas vigier a écrit :
+> On Wed, 27 Jun 2012, andre999 wrote:
+>
+>    
+>> nicolas vigier a écrit :
+>>      
+>>> On Wed, 27 Jun 2012, andre999 wrote:
+>>>
+>>>
+>>>        
+>>>> Thomas Backlund a écrit :
+>>>>
+>>>>          
+>>>>> andre999 skrev 27.6.2012 14:40:
+>>>>>
+>>>>>            
+>>>>>> Thomas Backlund a écrit :
+>>>>>>
+>>>>>>              
+>>>>>>> andre999 skrev 27.6.2012 10:47:
+>>>>>>>
+>>>>>>>                
+>>>>>
+>>>>>            
+>>>>>>>> I would favour adding the requirement that the dependancies of the
+>>>>>>>> backport must be available in the next release.  So that we would
+>>>>>>>> expect
+>>>>>>>>
+>>>>>>>>                  
+>>>>>>> This is esentially stating that we cant backport any bigger version to
+>>>>>>> mga2 /backports than mga3 will havein /release wich means when we hit
+>>>>>>> version freeze for mga3, it also freezes mga2 /backports...
+>>>>>>>
+>>>>>>>                
+>>>>>> I'm not following this point.
+>>>>>> What I mean is that if backport xx for mga1 requires yy version 12 in
+>>>>>> mga1, but yy is version 13 in mga2, we would define the requires for yy
+>>>>>> to accept versions 12 to 13 (or maybe wider).
+>>>>>>
+>>>>>>              
+>>>>> Point is what if you backport version 14 to mga1, and mga2 has version 13,
+>>>>> then upgrade path breaks.
+>>>>>
+>>>>>            
+>>>> No problem.  If the requirements of version 14 are present in mga2, then
+>>>> the backport will (very likely) continue to work normally.  If the versions
+>>>> of the required packages change, they will be updated with the upgrade.
+>>>> Since version 13 of mga2 is less than the version 14 of the backport, it
+>>>> won't be installed.
+>>>>
+>>>>          
+>>> There is no guaranty that requirements of version 14 mga1 backports are
+>>> all available in mageia 2. If it is linked with libsomething.so.1, but
+>>> mageia 2 only has libsomething.so.2, then there is a problem.
+>>>
+>>>
+>>>        
+>> That was my point.
+>> I was suggesting that it be required that backport requires be compatible
+>> with newer releases.
+>>      
+> And how do you check that it is compatible, without testing ? And how do
+> you test that it will be compatible with a newer release that is not yet
+> released ?
+>    
+
+You split in the middle of the point.  (The above sentence could have 
+been better worded.)
+See below.
+> Maybe we can also require that backports are bugfree, so we don't have
+> to manage backport updates.
+>    
+
+That would be nice, if you can see how to do it :D
+>    
+>> In your example, cauldron would probably require the libsomething.so.2, so
+>> if the backport requires could be adjusted to work with libsomething.so.1,
+>> we would keep the requires compatible with libsomething.so.2.  If that
+>> isn't possible, then it wouldn't be accepted.
+>>      
+> We cannot link a program with both libsomething.so.1 and
+> libsomething.so.2.
+>    
+
+If the spec file requires cannot be adjusted to accept linking with 
+whichever of the 2 is available, then in that case the backport wouldn't 
+be accepted - if my suggested restriction is accepted.
+
+>> I'm no expert of course, but it seems to me that it would be generally
+>> possible as long as there weren't important code changes made to make the
+>> backport work.
+>> So it would largely be a question of appropriately adjusting the specified
+>> requires.
+>>      
+> A lot of requires are generated automatically, we cannot change them
+> (and changing them would probably be wrong). And a lot of requires are
+> not versionned, but implicitly require the version available in the
+> same mageia release, without any guaranty that it works with a different
+> version.
+>    
+
+You mean generated automatically in the spec file ?  Surprising.
+If the require isn't versioned, since it would work in cauldron, and 
+also works in the backport release, then I would expect that it would 
+work in interim releases.  If it doesn't, that is in the risk of a backport.
+
+Don't forget, my suggestion is to increase the _probability_ that a 
+backport will work in interim releases.  Not to garantee that it will.
+In my experience, it is essentially the unavailability of required 
+packages that makes a package from an older release stop working.  A 
+backport would fit in this mold, except it will be a variation of what 
+is already working in cauldron.
+Collectively we may think it is not worth the increased reliability of 
+backports, but I think that for little effort we see an important gain.
+
+-- 
+André
+
+