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

Wed Jun 13 00:33:45 CEST 2012

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 would also have to ensure that the requires of the backport would be 
+available in the next stable release, which would be somewhat trickier, 
+but doable.  (In most cases this would not be a problem.)
+I think that we should fine-tune the rules so that we have both.  (Thus 
+restricting how we define the requires, etc, and also restricting what 
+can be backported in some cases.)
+Note that there are already some (loosely defined) restrictions on what 
+can be backported.
+
+Maybe we should have a group which approves backports (including the 
+spec file), based on upgradability and other criteria.  Especially in 
+the beginning, when the details will be less well-defined and packagers 
+less experienced with backports.  Something like what we did for 
+exceptions to the version freeze for mga2.  (Maybe approval by one of 
+the packager team leaders ? ;-) )
+We could make that a requirement for moving from backports-testing to 
+backports.
+
+> We can only have one in this list, so I think we need to decide which
+> one we want to keep.
+>
+> In my opinion, freezing backports of distribution N-1 when distribution
+> N is released is a serious limitation and we should not do this. Instead
+> I would say that easy upgrade when using new backports after release of
+> distribution N+1 is not guaranteed (but should still work in many cases).
+>    
+
+Agreed about not denying backports for N-1 releases.
+
+> Then users can decide to :
+> - not use backports if they plan to do an upgrade later and avoid any
+>    potential problem
+> - use backports, and do a reinstall instead of an upgrade
+> - use backports, do an upgrade, and know that in some case a few
+>    packages may need to be manually reinstalled. But there still
+>    shouldn't be important problems in most cases.
+>
+> We can provide a tool to list installed packages that are more recent
+> than version available in repository. This list can help to know which
+> packages may need to be reinstalled. But we don't know whether user
+> wants to revert to release or updates repository version, or use the
+> latest backports version.
+>    
+-- 
+André
+
+