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

[andre999]

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é