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>
For some modules, modularity-wg wants to be able to ship the "-devel" modules containing
the RPMs which are normally filtered out from the module.
This PR generates second Koji CG module with -devel suffix in a name with final modulemd
files containing the filtered out RPMs.
This will allow for tooling to automatically override certain buildrequires and requires
based on the branch name the modulemd is built form.
Addresses FACTORY-3414
Imagine we have "platform:f29.0.0" and "platform:f29.1.0" base modules.
We also have "DBI" module we want to build agaisnt "platform:f29.1.0".
This "DBI" module depends on "perl" module which is only build against
"platform:f29.0.0".
Currently, DBI build would fail to resolve the dependencies, because
it wouldn't find "perl" module, because it is built against different
platform stream.
This PR changes the MSE code to include buildrequired module builds built
against all the compatible platform streams.
It does so by introducing following changes:
- MSE code uses new get_base_module_mmds() method to find out all the
compatible platform modules. This needed new methods in DBResolver
and MBSResolver.
- For each buildrequired module defined by name:stream, the MSE code then
finds particular NSVC built against each compatible platform module.
Side effect of these code changes is that every module now must buildrequire
some base module.
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.
_get_mmds_from_requires does not do anything against db.session. Hence,
remove parameter session from it and
get_mmds_required_by_module_recursively.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
TestUtilsModuleStreamExpansion._make_module is moved to
tests/__init__.py so that other tests could reuse this to create a
module build.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
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.
Future use cases will require the ability to find compatible module builds
to buildrequire based on the base module the module used to build. This
commit adds an association table that will contain module build IDs
and the base module they buildrequire.
Addresses FACTORY-3353
The original Pungi code, on which MBS code is based on, always passed only RPMs
with valid architectures to further decide if their subset should end up in a
final modulemd file.
In MBS, we pass RPMs with all architecture and there was no code to actually filter
out the RPMs which are from architectures which should never end up in a final MMD.
This commit checks that RPMs for completely different architectures will never
be considered to be included in a final MMD.
system_resolver is created based on loaded configuration, which could
avoid calls like `GenericResolver.create(conf)` repeatedly in the code.
However, if some cases need to create a specific resolver explicitly,
`GenericResolver.create` could be called with addition argument, for
example db or mbs is passed to argument backend in tests.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
dup_nsvc prints version in hexadecimal instead of integer. This is found
in libmodulemd 1.6.2 f28 build. This bug has been fixed in upstream but
not release yet. Before the release, this patch formats NSVC manually to
workaround it.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
If a module has filters set and it buildrequires itself, issues occur
during component reuse. In that event, the filtered RPMs from the
previous module build will not be available in the buildroot because the NVRs
in the filters will match the RPMs from the reused component.
Co-authored-by: Jan Kaluza <jkaluza@redhat.com>
This reverts commit 8173040ea6. Since it didn't
provide any real benefit after talking with sgallagh, it seems like we'd better
off not introduce more risk to the next deployment.
This addresses an issue when a module contains builds that have different
names in their NVR than the component name in MBS. This happens with
SCLs for instance. MBS wouldn't be able to find the component to mark
as tagged in the database since it was searching by the wrong name, so the
build would just stall. This uses the NVR now to find the correct build
in the database.
MBS has been using the libmodulemd API incorrectly by assuming that
methods like `get_rpm_components` return the actual object in memory
and not a copy. This has been true but wasn't something sgallagh
intended. We found this out after he had me test his new version of
libmodulemd. This PR removes those assumptions.
