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

Wed Jun 13 01:48:06 CEST 2012

nicolas vigier a écrit :
+> On Tue, 12 Jun 2012, andre999 wrote:
+>
+>    
+>> nicolas vigier a écrit :
+>>      
+>>> On Fri, 08 Jun 2012, Samuel Verschelde wrote:
+>>>
+>>>
+>>>        
+>>>> Maybe we shouldn't open backports for Mageia 1, and make sure upgrade to
+>>>> Mageia 3 can take backports from Mageia 2 into account so that backports to
+>>>> Mageia 2 are not stopped when Mageia 3 is released. Then we'll be safe.
+>>>>
+>>>>          
+>>> I think we cannot have both :
+>>> - backports with higher version than in next stable release
+>>> - easy upgrade to next stable release
+>>>
+>>>        
+>> Why not ?
+>> We would have to ensure that the version of the backport is less than or
+>> equal to the version of the package (backport or not) in the next stable
+>> release.  We just have to follow the versioning policy of updates c.f.
+>> Cauldron, i.e. an update always has a version less than cauldron.  (Which
+>> allows for adding updates without changing the version of the next
+>> release.)
+>>      
+> We are talking about backports, not updates, so we don't care about
+> versionning policy of updates.
+
+OK.  I was just suggesting that we use the same approach.
+
+>   And backports can have higher version
+> than 'release' repository of next version, that's what this thread is
+> about.
+>    
+
+Indeed.
+I'm suggesting that in those cases where the version of the backport is 
+higher than the corresponding package of the next release, we ensure 
+that the backport will continue to function in the next version.  As I 
+see it, this entails primarily that the dependancies will be available.  
+We can assume that the dependancies are satisfied where the backport is 
+initially installed.  Given this, if these dependancies (or an update of 
+these dependancies) will function in next higher release, then I would 
+say that these conditions would be met, and the backport will continue 
+to function.  Thus we can ensure, by establishing the appropriate 
+policies, that backports can continue to function with release updates.
+
+Of course that will mean that in certain cases this won't be possible, 
+and I would suggest that in those few cases the backport be denied.  
+Cases such as a dependancy being obsoleted by a package that doesn't 
+provide all the functions needed by the backport.  Not a very common 
+occurance.
+We already have restrictions on backports, so I don't see this as a big 
+liability in exchange for reliable release updates.
+
+It is possible that this problem could be solved by creating a backport 
+for the next stable release, in which case to do the backport for 
+release N-1 we would have to first create a backport for release N.  
+This assumes that during or after the update to the new release, one 
+does a regular update, and that the update will automatically present 
+backports which apply to already installed backports, even if the 
+backport repo is closed.
+Obviously requiring a certain fine-tuning of the tools.
+
+-- 
+André
+
+