From 69e4ffa9b200913be7d95f54d30976e00d203ace Mon Sep 17 00:00:00 2001 From: Nils Philippsen Date: Nov 09 2017 17:36:20 +0000 Subject: [PATCH 1/2] add document to help with fixing dependency issues --- diff --git a/source/development/building-modules.rst b/source/development/building-modules.rst index c440a6c..a742463 100644 --- a/source/development/building-modules.rst +++ b/source/development/building-modules.rst @@ -59,4 +59,5 @@ Node.js 6 LTS release by running the command ``dnf install nodejs:6``. building-modules/adding-modules-to-fedora building-modules/building-infra building-modules/testing + building-modules/installation-dependency-issues building-modules/building-local diff --git a/source/development/building-modules/installation-dependency-issues.rst b/source/development/building-modules/installation-dependency-issues.rst new file mode 100644 index 0000000..bcb41b1 --- /dev/null +++ b/source/development/building-modules/installation-dependency-issues.rst @@ -0,0 +1,110 @@ + +Examining dependency issues during the installation of modules +============================================================== + +A common problem while installing a module is that one or more of its +components have requirements which cannot be fulfilled. + +This document describes scenarios in which this can happen and possible +solutions. It assumes that the module in question is successfully built in +official infrastructure and available on the examined system for installation. +You can verify the latter with ``dnf module list`` or ``dnf module list ``. + +Scenarios +--------- + +Dependency problems while installing a module can happen for a variety of +reasons: + +RPM-level packaging errors +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One of the packages involved is packaged wrongly, i.e. that the package is +available but carries a requirement which can't be fulfilled, for instance +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 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 +``data/filter/rpms`` section of the modulemd file. A likely reason that it is +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). +* 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. + +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. + +Package conflicts +~~~~~~~~~~~~~~~~~ + +If any of the packages which are installed on the system or would be installed +with the module conflict with each other because of the contained files, +version requirements or the like, these need to be resolved. How that is done +is outside the scope of this document. + +More detailed recipes +--------------------- + +Making a component available +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Adding a component to a module (or creating a new one) isn’t a one-step process +because the component may have unfulfilled dependencies of its own (which can +have other dependencies and so forth). Using a lather-rinse-repeat approach is +time-consuming (you’d have to wait for a compose to happen before testing the +changed module is possible) but the information to resolve these issues is +available from the outset, assuming that the dependencies are resolvable within +the set of Fedora packages. Instead of trying to resolve this manually (which +can be time-consuming on its own), one can use tools like |fedmod|_ to generate +the whole dependency chain programmatically. + +.. |fedmod| replace:: ``fedmod`` +.. _fedmod: https://pagure.io/modularity/fedmod + +The first step is to use ``fedmod rpm2module `` which creates a +modulemd file for a module containing the component and its dependencies. If +one wanted to do just that (and nothing failed) besides getting the module +reviewed and made available. Regardless of if the component should go into an +existing module or shouldn't be filtered out any longer, the information in the +generated modulemd file can be used to augment the module that should carry it +(arguably more work but still less than resolving dependencies manually, one at +a time). + +Removing dependencies +~~~~~~~~~~~~~~~~~~~~~ + +Often, removing dependencies is done by disabling a component feature that is +not needed in a module but would pull in a whole tree of other dependencies. +It would be the right approach more often for components that aren’t part of a +module’s API. This approach is trickier because you then need to introduce a +macro to enable or disable the functionality (and the dependencies in question) +in the spec file of the component, and you need to take care that its use in +``data/buildopts/rpms/macros`` doesn’t introduce side effects in the other +components which are built as part of the module. From 8cd37224a131d024dbdf3ebd68eb65f4e177cca4 Mon Sep 17 00:00:00 2001 From: Nils Philippsen Date: Nov 09 2017 17:36:20 +0000 Subject: [PATCH 2/2] add section about identifying components --- diff --git a/source/development/building-modules/installation-dependency-issues.rst b/source/development/building-modules/installation-dependency-issues.rst index bcb41b1..7e47591 100644 --- a/source/development/building-modules/installation-dependency-issues.rst +++ b/source/development/building-modules/installation-dependency-issues.rst @@ -97,6 +97,26 @@ generated modulemd file can be used to augment the module that should carry it (arguably more work but still less than resolving dependencies manually, one at a time). +Identifying components +~~~~~~~~~~~~~~~~~~~~~~ + +Consider this error while attempting to install a module ``389-ds``:: + + $ dnf module install 389-ds + Fedora - Bikeshed - Developmental packages for the next Fedora release 8.5 MB/s | 3.5 MB 00:00 + Last metadata expiration check: 0:00:00 ago on Fri 13 Oct 2017 02:44:48 PM UTC. + Error: + Problem 1: conflicting requests + - nothing provides libtcmalloc.so.4()(64bit) needed by 389-ds-base-libs-1.3.7.4-1.module_506864e9.x86_64 + Problem 2: conflicting requests + - nothing provides libtcmalloc.so.4()(64bit) needed by 389-ds-base-1.3.7.4-1.module_506864e9.x86_64 + +In this case one needs to find out which package provides +``libtcmalloc.so.4()(64bit)``, e.g. by running ``dnf repoquery --whatprovides +`` on an (as of now at least) not yet modular Fedora system and if +necessary ``dnf info `` to find out the source package which can then +be added to a module. + Removing dependencies ~~~~~~~~~~~~~~~~~~~~~