#85 Cover filtering out RPMs as a dependency trouble-shooting strategy
Merged 6 years ago by ncoghlan. Opened 6 years ago by nphilipp.
nphilipp/modularity master--fixing-deps  into  master

@@ -28,15 +28,15 @@ 

  listed as being satisfied by the package carrying it. Solving this is beyond

  the scope of this document.

  

- The package is available in another module

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ The dependency can be satisfied by another module

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  

  Another available module contains a package which would satisfy the requirement

  but that module isn't pulled in as a runtime dependency. In most cases adding

  that missing dependency should fix the issue.

  

- The package is filtered out

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ Another module could satisfy the dependency in theory but doesn't

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  

  A package that would satisfy the requirement is built by this or another

  available module but is filtered out after building, by being listed in the
@@ -45,23 +45,25 @@ 

  requirements can't be fulfilled. Depending on the circumstances, there are

  different possible approaches:

  

- * Not filter the package out (and solve any issues it may have in the process).

+ * Not filter the package out in the other module (and solve any issues it may

+   have in the process).

  * Remove the hard dependency from the package that depends on it. For instance,

    there are a lot of packages with hard dependencies which should rather be

    weak ones, but weak dependencies didn't exist in Fedora by the time these

    dependencies were created. In this case converting that hard ("Requires:") to

    a weak dependency ("Recommends:") can do the trick.

+ * Filter out the package pulling in the dependency in the first place.

  

  The package isn't part of any available module

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  

  If a package that would fulfill a dependency isn't part of any available

- module, the options are to add it to an existing module as a component or to

- create a new module for it. If the component on its own is only useful in

- conjunction with the software contained in the module that can't be installed

- the best place is to put it there. If it has wider uses, a decision needs to be

- made if another existing module or a newly created one is the best place for

- it.

+ module, one can add it to an existing module as a component or to create a new

+ module for it (if filtering out the package that causes the dependency isn't an

+ option). If the component on its own is only useful in conjunction with the

+ software contained in the module that can't be installed the best place is to

+ put it there. If it has wider uses, a decision needs to be made if another

+ existing module or a newly created one is the best place for it.

  

  Package conflicts

  ~~~~~~~~~~~~~~~~~
@@ -74,6 +76,22 @@ 

  More detailed recipes

  ---------------------

  

+ General considerations

+ ~~~~~~~~~~~~~~~~~~~~~~

+ 

+ Fixing component-level dependency issues can generally be done in two ways:

+ Either by providing whatever is missing or by removing the need for it in the

+ first place.

+ 

+ Filtering out packages

+ ~~~~~~~~~~~~~~~~~~~~~~

+ 

+ If a package whose dependency can't be fulfilled isn't part of the API of the

+ module or required directly or indirectly by an API package it can be filtered

+ out by adding it to the ``data/filter/rpms`` list in the modulemd file. This is

+ an approach that usually requires little work beyond establishing that these

+ prerequisites are met.

+ 

  Making a component available

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  

Pull-Request has been merged by ncoghlan

6 years ago