This also moves the methods load_mmd and load_mmd_file to
module_build_service.utils.general.
This also removes some MSE unit tests with a mix of positive and
negative streams since this is not supported in libmodulemd v2. The
user will be presented with a syntax error if they try to submit
such a modulemd file.
This fixes problems from #1184 when new platform stream is added and the
input module depends on another module which is not built against this
new platform, but in the same time the input module wants to be built
against this new platform stream. See the unit-test for more info.
The problem is that `MMDResolver.solve()` method sets the `alternative`
to an empty list and stores the data there only if the alternative
is found valid. If the alternative is not found valid, then it stays
set to an empty list, but the code using `alternative` later expects
it to only contains valid alternatives.
This commit fixes this by setting the `alternative` only in a case
we found it is valid alternative.
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.
During I'm reading through the code base to learn MBS, I found out some
typos and minor issues in some other docstrings, and I also found some
docstrings with extra informative description could make it easier to
understand the code.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
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>
Conflicting with module(foo) is more than enough to make sure that we
will have only one copy of solvables providing it.
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>
