From Fedora Project Wiki
(create)
 
(Taskotron EOL)
 
Line 1: Line 1:
{{admon/caution|Taskotron development reached end of life|[[Taskotron]] has been sunset in Fedora Infrastructure. It is no longer running and no longer being developed. You can use these wiki pages to learn about its history, but please be aware that the information is no longer actual.}}
= What is rpmdeplint? =
= What is rpmdeplint? =
Rpmdeplint was created to detect package builds with broken dependencies. Task-rpmdeplint is a [[Taskotron]] wrapper around that tool. It replaced an older [[Taskotron/Tasks/dist.depcheck|depcheck]] check.
Rpmdeplint was created to detect package builds with broken dependencies. Task-rpmdeplint is a [[Taskotron]] wrapper around that tool. It replaced an older [[Taskotron/Tasks/dist.depcheck|depcheck]] check.

Latest revision as of 14:47, 7 May 2020

Stop (medium size).png
Taskotron development reached end of life
Taskotron has been sunset in Fedora Infrastructure. It is no longer running and no longer being developed. You can use these wiki pages to learn about its history, but please be aware that the information is no longer actual.

What is rpmdeplint?

Rpmdeplint was created to detect package builds with broken dependencies. Task-rpmdeplint is a Taskotron wrapper around that tool. It replaced an older depcheck check.

How does rpmdeplint task work?

Rpmdeplint task computes package dependencies of proposed updates and evaluates whether these dependencies are satisfied. The whole set of builds submitted to a certain repository (fedora, updates or updates-testing) is always considered together -- even though Bodhi update should be completely standalone, rpmdeplint will be able to find and resolve dependencies between individual updates, as long as they are submitted together (request to be pushed to the same repository at the same time).

Known deficiencies

At the moment, rpmdeplint task only decides whether each of the submitted builds is installable. This is equivalent to trying to install that build into a completely empty environment (no RPM packages pre-installed). If some other package build (that is already present in the target repository) gets broken as a result of this, that's not currently detected by this task. The detection is supported by the underlying rpmdeplint tool, it just hasn't been implemented yet in the task (stay tuned).

Understanding Failures

Looking at an example failure log, we see the following:

results:
- arch: x86_64
  item: wine-1.9.21-1.fc24
  outcome: FAILED
  scenario: x86_64
  type: koji_build


nothing provides wine-mono = 4.6.3 needed by wine-1.9.21-1.fc24.i686
nothing provides wine-mono = 4.6.3 needed by wine-1.9.21-1.fc24.x86_64

This is a similar message that you should see when trying to install this package using Package-x-generic-16.pngdnf, so hopefully it should be quite readable what the broken dependency is and how to debug the issue further.

Fixing Failures

Fortunately, the fixes for dependency errors tend to be relatively straight-forward and tend to fall into one of two categories listed below.

  1. Problems caused by your package
    Examine any changes to Provides, Requires or BuildRequires in the spec file. Ensure correct spelling of all dependencies and confirm that any changed requirements do resolve for the appropriate release. If the dependencies of your package have not changed, it's possible that other packages no longer satisfy the dependencies as expected.
    The command dnf repoquery is helpful to track dependencies.
  2. Problems caused by other package(s)
    If your package failed because the dependencies of other packages changed (features they were providing changed or were removed), update the requirements of your package or consult with maintainers of the corresponding packages.

Getting Help

If you still don't understand why your update failed the test, if you think there's something wrong in our test or its documentation or if you have any other suggestions, please contact us.

Additional Information