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é
