- Python 98.7%
- Shell 1.3%
|
All checks were successful
CI via Tox / tox (pull_request) Successful in 1m50s
Packaging two Python scripts, one of which is a wrapper for the other, is pretty awkward. But more importantly, we can make the EL "wrapper" work better with a refactor, too. It's now a stand alone script called `rdc-compose`. The original script is renamed to `rdc-repos`. The CLI scripts now share a lot of bits via `shared.py`. We put handy run-it-locally wrappers for each CLI script at the top level; you *can* install the package properly and you'll get `rdc-repos` and `rdc-compose` executables but we'll likely rarely do that. `rdc-compose` will now run faster because it will reuse the same metadata between variants (previously it got re-downloaded with every execution of `rmdepcheck.py`) and it can now nicely collect up all the repoclosure strings before using the same parse-and- exit code as rmdepcheck, which solves a lot of awkward issues around output. We also add tests covering `rdc-compose`, as part of which it made sense to factor out the Pungi config URL discovery (which I meant to do anyway). We fix a bug that was exposed by writing the tests: we have to check variants that depend on variants we have packages for, even if we don't have packages for those variants. This isn't great git hygiene, sorry. Should have made the refactor, the addition of tests and the bug fix into separate commits. But it's awkward and time-consuming to unpick now and I don't think it's a good use of time. Signed-off-by: Adam Williamson <awilliam@redhat.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| src/rmdepcheck | ||
| tests | ||
| .gitignore | ||
| CHANGELOG.md | ||
| COPYING | ||
| install.requires | ||
| pyproject.toml | ||
| rdc-compose | ||
| rdc-repos | ||
| README.md | ||
| release.sh | ||
| tests.requires | ||
| tox.ini | ||
| tox.requires | ||
rmdepcheck
rmdepcheck is an RPM dependency check tool based on a repository metadata modification approach. It exists as an installable library, but is not usually intended to be installed or imported; you are meant to use one of the two CLI interfaces, which can be run directly with no need for installation.
rdc-repos
rdc-repos is the original form of rmdepcheck. It works by comparing a checked repository to one
or more base repositories. First, checks are run on the base repositories as-is. Next, we re-run
the checks, but with the checked repository available and using dnf's excludepkgs option to hide
from the base repositories all packages from the same source RPM(s) as the package(s) in the
checked repositories removed. The results of the two runs are compared. New failures should
indicate problems introduced by the checked repositories. Also, some relevant checks are run on the
checked repositories with reference to the modified base repositories.
Optionally, other types of repository can be specified:
- Additional base repositories which will not be modified or checked ("non-modified base repos")
- Additional base repositories which will be modified but not checked ("non-checked base repos")
- Additional new repositories can be specified which will not be checked directly
Non-modified base repos are intended for testing scenarios like stable Fedora releases, which have a frozen release repository which is never modified, and an updates repository which is updated.
Non-checked base repos and additional new repos are intended for Enterprise Linux distributions. These have multiple variants with repositories, and "dependencies" among them, e.g. packages in the HighAvailability variant can depend on packages in the BaseOS and Appstream variants. We may be testing an update containing packages destined for all three variants, which we split into three repositories. When testing the HA repository, we would want to have the "new package" BaseOS and Appstream repositories "in scope" but not checked ("additional new repositories"), and the "base" BaseOS and Appstream repositories "in scope" and modified, but not checked ("non-checked base repositories").
Additional new repositories might also be used for multilib scenarios; it may be desirable to use such an additional repository for packages for the multilib arch(es), if e.g. installability of these should not be tested directly.
An alternative mode allows simply testing the consequences of removing a list of source packages entirely; in this mode, in the second step, we exclude all binary packages built from the specified source packages. The installability check is skipped in this context.
rdc-compose
rdc-compose is alternative interface which takes a distribution compose URL (this must be a Pungi / productmd-style compose) and a local filesystem path containing the packages under test as inputs. It discovers the variants contained in the compose, splits the packages-under-test into per-variant repositories, and then checks those against the target compose appropriately in much the same way described above, testing appropriate sets of variants against each other according to the rules on which variants can depend on packages from which other variants. This is a lot of work but should provide the most accurate and useful results.
Requirements
rdc-repos has no run-time Python dependencies outside the standard library. rdc-compose requires the requests and urllib3 libraries. Both scripts require dnf; rdc-compose also requires createrepo. The scripts checks for their dependencies, and will exit early with an error if they are not found. rmdepcheck is written primarily for Red Hat-family distributions, but should in theory be usable anywhere these dependencies can be installed (and forward slashes act as directory separators).
If you use a version of dnf older than 5.2.15.0, you may see false failures for 'rich' dependencies, as older dnf versions did not handle these correctly. Use 5.4.0.0 or newer for the best handling of 'rich' dependencies (5.2.15.0 through 5.3.0.0 ignored them entirely; 5.4.0.0 checks them correctly).
Installation
Installation of rmdepcheck is entirely optional, it can be run just as well directly from the
repository. Otherwise, rmdepcheck uses setuptools for installation and is PEP 518-compliant. You
can build and install with e.g. the build module and pip. rmdepcheck can also be installed
directly from PyPI with pip and other tools.
Usage
Simple usage looks like this:
rdc-repos https://a.base.repo.example/repo,file:///another/baserepo file:///the/testedrepo
The repositories are specified as a comma-separated list. Repositories should be specified as URLs, but for convenience, file:// can be omitted. Only file:// , http:// and https:// URLs are accepted.
For the alternative 'removal' mode, usage looks like:
rdc-repos --removes https://a.base.repo.example/repo,file:///another/baserepo sourcepkg1,sourcepkg2
This tests removing sourcepkg1 and sourcepkg2, and all binary packages built from them, from the base repositories.
If you want to test repositories containing packages of an arch that does not match the system on
which you are testing, pass --arch <arch>, where <arch> is the arch you wish to test.
For more complex usage, see rdc-repos --help.
rdc-compose usage looks like this:
rdc-compose https://kojipkgs.fedoraproject.org/compose/eln/latest-Fedora-eln/compose /the/testedrepo
An optional --arch arg can be passed as for rmdepcheck. Note that you MUST NOT include
file:// in the tested repo arg, and it MUST be a local filesystem path. rdc-compose does not
support remote tested repos.It does not actually need to be a repository; it just needs to be a
directory with RPMs in it.
Testing build dependencies
You can include source package repositories in the base repository set. This has the effect of
testing for build dependency breakages, as the dependencies of a source package are its build
requirements. You can identify build dependency breakages in the output by the package name ending
in .src.
When doing this, you must also include at least one matching binary repository, or all requirements of all source packages will be unresolvable and the tool will run slowly and produce useless output.
Example:
rdc-repos https://a.base.repo.example/binaryrepo,https://a.base.repo.example/sourcerepo file:///the/testedrepo
License
rmdepcheck is released under the GPL, version 3 or later.
See COPYING and the header of rmdepcheck.py itself.
Contributing
Issues and pull requests can be filed in Fedora Forge.
ANY USE OF AI/LLM IN THE PRODUCTION OF A PULL REQUEST MUST BE CLEARLY DISCLOSED. This is for legal reasons, as the copyrightability of LLM-generated code is (as of April 2026) disputed and unclear. This is also for technical reasons, as reviewers may need to look out for different problems when reviewing LLM-generated code, compared to human-generated code.
Please include an Assisted-by line in the commit message, specifying the model, tool and/or
service used in creating the pull request, and a more detailed explanation of how LLM technologies
were used in the pull request description. This can be copied/pasted from PR to PR if the workflow
remains the same.
Here is a sample commit message:
Make the frobnosticator reticulate splines better
By rejigging the frobnosticator, we can reticulate splines twice as fast!
Signed-off-by: Bob Roberts <bob@example.com>
Assisted-by: OpenCode 1.3.15 | claude-4.6-opus-high
Pull requests must be signed off (use the -s git argument). By signing off
your pull request you are agreeing to the
Developer's Certificate of Origin:
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.