This just simplifies the code. It doesn't change the functionality
at all. The tests had to be changed because it assumed that the
xmd.mbs.buildrequires section would be filled out for the input
module which isn't true.
This commit fixes issue with following situation:
Module `foo` has been built with `buildrequires: platform: [f28]`
and `requires: platform: []`. It can therefore be used as a buildrequirement
on any platform stream. But if you want to build module `app` which
buildrequires `foo` on `platform:f30`, the MBS won't pull-in the `foo`
module build, because MBS currently limits the modules by the platform
they have been built for.
This commit adds new config option to allow including modules built
against any platform stream.
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.
A base module's stream (the platform for RHEL) could have Z-stream suffix, e.g.
el8.0.0.z, this patch handles this Z-stream suffix and other potential streams
by returning the stream version as a float with configured suffix value. For
example, el8.1.0.z would be parsed as 080100.1. Note that, the 0.1 is totally
configured in config and it actually could be any value according to concrete
cases in practice.
Config STREAM_SUFFIXES is enabled in TestConfiguration so that tests depending
on the return value from ModuleBuild.get_stream_version are covered.
Part fixture of test TestMMDResolver.test_solve_virtual_streams is updated by
adding Z-stream suffix to platform:el8.2.0 in order to ensure this patch does
not break the MMD resolver.
Addresses FACTORY-4307
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
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.
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>
