For an explanation of transitive stream collision, please refer to the
source code docstring.
When such collision is detected, error is raised with proper error
message.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
The test tests installation of multiple streams of single module.
For example:
- "app:1" requires "foo:1" and "gtk:1".
- "foo:1" requires "bar:1".
- "gtk:1" requires "bar:2".
"bar:1" and "bar:2" cannot be installed in the same time and therefore
there need to be conflict defined between them.
Modularity team needs to be able to define multiple streams for single "platform"
module. They need it to express that "platform:el8.1.0" also provides "platform:el8".
This needs changes in a way how MMDResolver resolves dependencies between modules.
For example, if we are building module against platform:el8.1.0, the MMDResolver must
not return buildrequired module built against platform > el8.1.0, but it can for example
return (cherry-pick) buildrequired module from platform:el8.0.0 if there is no such
module built for platform:el8.1.0.
The way how it is implemented is following:
- MMDResolver reads list of virtual streams from xmd["mbs"]["virtual_streams"] when
creating Solvable from MMD and adds additional Provides for these virtual streams.
We expect these to be set mainly on base modules. The versions of such provides
are based on "stream version" number, so we can compare them.
- The base module ("platform") buildrequires of MMDs added to MMDResolver are overriden
to mark particular platform "stream version". For example, if module "foo" buildrequires
"platform:el8" in MMD file, but was in fact built against platform:el8.1.0, it will
be treated as if it would really buildrequire "platform:el8.1.0". This is needed
to not include buildrequired modules built against newer platform than what we want.
- MMDResolver resolves all the valid combinations of buildrequires, but we are only
interested in the one with latest versions of buildrequired module. Therefore the
solve() method is changed to find out combinations which have the latest versions
for each alternative name:stream buildrequires.
Now we have good separation between runtime and buildtime dependencies:
If mmd has context, it is built artefact which supposed to have only one
dependency entry, we create solvable with real arch for it. Otherwise we
create multiple solvables with "src" arch.
In "src" solvables, "context" is a number which represents index in
dependencies array.
Stream is not included anymore in "evr" because it's incomparable.
Version is not included anymore in "name" because it's there just for
comparison, nothing more (it's not different module-stream).
As a side, add_requires/add_conflicts/add_provides were replaced with
non-deprecated add_deparray method.
With all this, we are ready to handle MMDs which have multiple elements
in dependencies (modulemd v2).
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Previous version was assuming that number of alternatives is static
which is wrong, they can be appearing depending on solvables.
Also it was checking even impossible combinations (due to using
itertools.product).
Now we check only real possibilities.
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
