fedora-ci / general

#522 Run rmdepcheck as a generic test (like rpminspect, rpmdeplint)
Closed by lecris. Opened by adamwill.

Closed
Reopen Issue

I want to propose adding a run of my rmdepcheck tool as a generic test - like rpminspect and rpmdeplint and so on. That is, a test that would be run on all Fedora updates.

I've been trialling the tool in openQA - it's run on all updates for which the openQA everything-boot-iso tests are triggered, which is quite a few - and so far the results look positive; it detects dependency failures and doesn't seem to produce false positives. So I'd like to move to the next step, running it in Fedora CI on all updates. Eventually I'd like to make it a gating check.

Implementation should be pretty easy as the tool does not use system repositories. It can run from any environment with dnf (preferably dnf5, but 4 will work), zstd and curl. So the tests for all updates could be run from a single container environment.

All the pipeline really needs to do is make sure dnf, zstd and curl are available, create a repository containing the packages under test (we have this implemented already, right?), then run:

git clone https://codeberg.org/AdamWill/rmdepcheck.git
cd rmdepcheck
./rmdepcheck.py https://kojipkgs.fedoraproject.org/repos/f<RELNUM>-build/latest/<ARCH> file://<PATH TO PACKAGE REPO>

rmdepcheck can also be installed from pypi; I haven't packaged it yet, but can if need be. The first arg is https://kojipkgs.fedoraproject.org/repos/eln-build/latest/<ARCH> for ELN.

Tests for different arches don't need to be run on the same arch, so we can potentially test all arches in a single pipeline run on any arch.

The command exits 0 for success, 1 if the update breaks deps of other packages, 2 if it has broken deps itself, 3 if both. By default it prints human-readable text output which can be reported, --json can be used to produce structured JSON output instead.

I am starting to sketch out the initial setup, so I got a few questions while writing this:

  • This can be run on any OS right, and the place that decides what OS to effectively run on is the first variable for rmdepcheck.py?
  • How do we cover epel setups? epel-next would be the most annoying bunch to consider

  • The second one I presume is the a repo file of the format used in /etc/yum.repos.d. Will need to figure out how to minimally prepare a few variants from:

    • scratch-build koji
    • bodhi update
    • copr

Would like to avoid creating those repo files from cli in order to avoid dependencies
  1. Any OS with a version of dnf that implements repoclosure, yeah (and zstd and curl).
  2. So far I have not looked at EPEL. Fundamentally what you need to figure out to "support" a release is "what is a sensible set of base repos to test against for this release?" So far, for me, the best answer has always been "just use the buildroot repo". But we don't have to do this anyway, do we? It seems like we already run fewer (or none) of the 'generic' tests on the various EPEL branches, looking at Bodhi.
  3. If by "the second one" you mean "the second variable", no. All the repo variables for rmdepcheck are URIs to repositories, not yum/dnf repo config files. They can be http, https or file URIs. The location they point to must be a yum/dnf repository - that is, it must have a repodata/ subdirectory with appropriate metadata in it. I was kinda assuming Fedora CI already has the capability to create/provide a repository containing the packages under test, but if not, it's not particularly difficult, you just shove the packages in a directory and run createrepo on it.

Implementation is up at https://github.com/fedora-ci/rmdepcheck-pipeline/pull/1

Currently only for x86_64 and Fedora branches, will evolve it as it goes.

It's alive!

Metadata Update from @lecris:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.