Project

Profile

Help

Issue #4962

Updated by dalley over 5 years ago

When Pulp tries to copy a module like openmpi or mariadb from the Fedora modular repository (https://dl.fedoraproject.org/pub/fedora/linux/updates/30/Modular/x86_64/), using either the recursive or recursive-conservative depsolving strategies, it will additionally (and incorrectly) copy modules like perl, perl-bootstrap, and setools.  

 This happens because one of the artifacts in these modules (modules: openmpi (openmpi and mariadb) depends on the perl package, which is meant to be provided by the normal Fedora repositories. However in this case there also exists a "perl" module, and libsolv tries to use artifacts from the "perl" module to satisfy the dependency.    This should not happen because the openmpi and mariadb modules do not not declare a modular dependency in the "dependencies" section of their modulemd documents. 

 Dependency solving uses a libsolv "pool" that contains the entire contents of the source repository, and in conservative mode, also the entire contents of the target repository.    We need to change the behavior of the depsolver such that such that all non-modular RPMs in the pool are "considered" during depsolving, but only the modular RPMs that are part of the module being copied or an explicitly listed modular dependency are "considered", and all others are excluded from depsolving. 

 I'm unsure if a mechanism to do hide certain units from the depsolver is exposed to us, see: https://github.com/openSUSE/libsolv/issues/258. 

 If not, it may be necessary to hack around the problem by being more selective about what module / modular artifact solvables units we load into the pool to begin with.   


 


 <pre> 
 --- 
 document: modulemd 
 version: 2 
 data: 
   name: openmpi 
   stream: 4.0 
   version: 3020190331170644 
   context: a5b0195c 
   arch: x86_64 
   summary: Open Message Passing Interface 
   description: >- 
     Open MPI is an open source, freely available implementation of both the MPI-1 
     and MPI-2 standards, combining technologies and resources from several other projects 
     (FT-MPI, LA-MPI, LAM/MPI, and PACX-MPI) in order to build the best MPI library 
     available.    A completely new MPI-2 compliant implementation, Open MPI offers advantages 
     for system and software vendors, application developers, and computer science 
     researchers. For more information, see http://www.open-mpi.org/ . 
   license: 
     module: 
     - MIT 
     content: 
     - BSD and MIT and Romio 
   dependencies: 
   - buildrequires: 
       platform: [f30] 
     requires: 
       platform: [f30] 
   references: 
     community: https://www.open-mpi.org/ 
     documentation: https://www.open-mpi.org/doc/v4.0/ 
     tracker: https://github.com/open-mpi/ompi/issues 
   profiles: 
     buildroot: 
       rpms: 
       - openmpi-devel 
     default: 
       rpms: 
       - openmpi 
   api: 
     rpms: 
     - openmpi 
   components: 
     rpms: 
       openmpi: 
         rationale: The core package 
         ref: 4.0 
         buildorder: 10 
         arches: [aarch64, armv7hl, i686, ppc64le, s390x, x86_64] 
   artifacts: 
     rpms: 
     - openmpi-0:4.0.1-1.module_f30+3806+d6645847.src 
     - openmpi-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - openmpi-debuginfo-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - openmpi-debugsource-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - openmpi-devel-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - openmpi-devel-debuginfo-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - openmpi-java-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - openmpi-java-devel-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - python2-openmpi-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
     - python3-openmpi-0:4.0.1-1.module_f30+3806+d6645847.x86_64 
 ... 
 </pre> 


 See: no "dependencies" listed beyond the standard "platform" 

 The openmpi-devel package is the one that has a requires on /usr/bin/perl 

 "requires: /usr/bin/perl"  

Back