From aace4003d832c9de5f749970bc61bf0d4e940e3c Mon Sep 17 00:00:00 2001 From: Nils Philippsen Date: Nov 10 2017 16:43:18 +0000 Subject: [PATCH 1/2] use a bit clearer wording --- diff --git a/source/development/building-modules/installation-dependency-issues.rst b/source/development/building-modules/installation-dependency-issues.rst index 9b5f180..1573e76 100644 --- a/source/development/building-modules/installation-dependency-issues.rst +++ b/source/development/building-modules/installation-dependency-issues.rst @@ -28,15 +28,15 @@ because of typos, versioning issues, requiring a private library that isn't 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,7 +45,8 @@ listed there is that it in turn isn't installable because one of its 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 From ef38c5493e7f6dc53ec900fc6619eac7e6773c4d Mon Sep 17 00:00:00 2001 From: Nils Philippsen Date: Nov 10 2017 16:43:32 +0000 Subject: [PATCH 2/2] describe filtering out packages fixes issue #80 --- diff --git a/source/development/building-modules/installation-dependency-issues.rst b/source/development/building-modules/installation-dependency-issues.rst index 1573e76..0e52dc1 100644 --- a/source/development/building-modules/installation-dependency-issues.rst +++ b/source/development/building-modules/installation-dependency-issues.rst @@ -52,17 +52,18 @@ different possible approaches: 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 ~~~~~~~~~~~~~~~~~ @@ -75,6 +76,22 @@ is outside the scope of this document. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~