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

Fri Jun 8 16:58:24 CEST 2012

Samuel Verschelde a écrit :
+> Le vendredi 8 juin 2012 16:11:07, andre999 a écrit :
+>    
+>> Sander Lepik a écrit :
+>>      
+>>> 08.06.2012 11:38, Samuel Verschelde kirjutas:
+>>>        
+>>>> I re-read the backports policy, and there's a part I think needs to be
+>>>> pointed out before people start to backport packages.
+>>>>
+>>>> "We need to ensure that upgrades never fail: cauldron must always have a
+>>>> higher version/release than in stable releases."
+>>>>
+>>>> This statement is true, but implies more than what it says. It means
+>>>> that we can't backport a package for Mageia 1 with a higher version
+>>>> than what we have in Mageia 2 release (and updates?) media. And this,
+>>>> until we are able to take backports into account during upgrades.
+>>>>
+>>>> Example :
+>>>> - Mageia 2 has wesnoth 1.10.2 in core/release
+>>>> - Mageia 1 can't get a higher version in its backports media
+>>>>
+>>>> Do you all agree with my understanding of the policy ?
+>>>>          
+>> I see your point.
+>> In most cases, a backport for mga1 would be essentially identical for
+>> mga2 (except package file name and corresponding changes in the spec file).
+>> It would only differ if dependancies differ, which I suspect is unlikely
+>> for wesnoth or most other games, for example.
+>> So this means that for a backport to mga1, we should first do one to mga2.
+>> This would more than likely be done at the same time by the same
+>> packager, so not much more work.
+>> The demand for backports to mga1 is not likely to be very high, and
+>> would depend on a willing packager.
+>>      
+> 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.
+>
+> Samuel
+>
+>    
+But wouldn't current tools update backports if backports are active ?  
+(At least in an update after the release update.  Personally I alway do 
+an update step after a release update, as I never have a reliable 
+connexion during a release update, which I do from dvd.)
+This reinforces my idea that all backports should be tagged as 
+backports, and the tools adjusted for that.  Then backports could be 
+updated during the release update, instead of as a separate step afterwards.
+Maybe we should hold off on backports until we ensure that all backport 
+packages are tagged as such.
+See my comment about tagging backports on the backport policy discussion 
+page.
+
+This adds another factor to be considered in release updates.  The tools 
+should be changed for this before we have any problematic backports.  
+Leaf packages shouldn't cause a problem, besides the package itself 
+maybe not working properly.  In updates after the version update, the 
+user would see suggested updates with the current tools, as long as the 
+versions were appropriate, and backports were active.
+
+-- 
+André
+
+