| |
@@ -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
|
| |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| |
|
| |
This should fix issue #80.
/cc @ncoghlan