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

Sun Jun 10 08:11:10 CEST 2012

Thomas Backlund a écrit :
+> 09.06.2012 13:29, andre999 skrev:
+>    
+>> OK.  To backport from Cauldron to mga1, we have to backport from
+>> Cauldron to mga2, (bumping the revision in cauldron to ensure that is is
+>> higher), then backport from mga2 to mga1, ensuring that the revision is
+>> lower in mga1 than in mga2.    (e.g. revision x.1 in cauldron, x.0.1 in
+>> mga2, x.0.0.1 in mga1)  Pretty straight forward.
+>>
+>>      
+> Not needed as 1.mgaX>  1.mga3>  1.mga2>  1.mga1
+>    
+
+I was thinking of available packages changing between mga1 and mga2, but 
+if the backport is installed (with whatever requires being installed), 
+these requires wouldn't (or shouldn't) be removed with a release update 
+from mga1 to mga2.
+
+But what do we do if a package required for installing the backport in 
+mga1 is not available due to conflicts in mga2 ?  Do we assume that the 
+conflicting package in mga2 has the appropriate provides, or even can 
+provide the required function ?
+Or do we try to detect such situations and remove the backport in question ?
+
+If we make a point of making a backport for mga2 (or upgrade if it 
+doesn't have to be a backport in mga2), then this problem would already 
+be resolved.
+Of course, most of the time this wouldn't be a problem, and we could 
+check for requires that are not available in mga2.
+Another thing that we should verify is the version specified for 
+requires.  That is very likely to change between release versions.
+
+Maybe a rule that the requires specified for the backport in the target 
+release should be compatible with Cauldron.
+That is, that all packages required for the backport in the target 
+release are provided in Cauldron (either by provides or the specific 
+package), and that the versions specified - if any - are compatible with 
+the versions available in Cauldron (and of course the target release).
+This should ensure that the requires would be available in any interim 
+releases.
+
+>> - Cherry-picking refers to the users' option to install a backport,
+>> which has nothing to do with the packaging itself.
+>>
+>>      
+> Oh but it has _everything_ to do with packaging...
+>
+> in order for cherrypicking to work, the deps must be stricter so
+> that any deps in backports gets selected along with the package
+> the user is selecting.
+>    
+
+I was assuming that the requires would be well defined for a backport, 
+as they should be for any package.
+
+It would be nice to have a tool to check for dependancies, if there 
+isn't one already.
+To avoid overlooking something because the test systems have some of the 
+dependancies already installed.  Particularly since QA would be less 
+implicated in the testing.
+> --
+> Thomas
+>
+>    
+-- 
+André
+
+