Prepare for DNF 5, don't depend on `dnf` (I'm filing issues with all the packages that currently depend on `dnf`.) DNF 5 is a new package manager that will replace DNF 4 in Fedora 39+: Starting in Fedora 39, the `dnf` command will be provided by the `dnf5` package rather than the `dnf` package, and `dnf5` will obsolete `dnf`. Since supermin currently depends on DNF 4, it should choose one of the following strategies to avoid breaking the Fedora upgrade: - Add support for DNF 5, and depend on the `dnf5` package in Fedora 39+ instead of `dnf`. Builds of DNF 5 are available in this COPR repository: https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/, and documentation is available here: https://dnf5.readthedocs.io/en/latest/. - Alternatively, or in the meantime, change the supermin and supermin-devel packages to depend on `python3-dnf` instead of `dnf`, and call the `dnf-3` binary instead of `dnf`. The old DNF 4 command will still be available in the distribution, but only as `dnf-3` (the binary is called `dnf-3` rather than `dnf4` for historical reasons; it is the "Python 3 version" of DNF). The first option is preferred to this one; it is not recommended to modify installed software using both DNF 4 and DNF 5 on the same system. - Or, if this package is no longer being maintained, consider removing it from Fedora. At some point, this project should adopt DNF 5, but the immediate issue is removing the dependency on `dnf`. We are planning to replace DNF with DNF5 in Fedora Rawhide very soon, by 2023-06-01, and the supermin and supermin-devel packages will break as long as they still depend on the `dnf` package. For more information about the switch to DNF 5, see https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5. Reproducible: Always
I don't get it - the COPR has dnf 4 (and all the Rawhide builds failed), not dnf 5 or dnf5.
Will the new binary always be called "dnf5"? Or is it going to be called "dnf"? The program has different behaviour, eg. does not support the -v option, so this matters since if we just see a "dnf" program we will need to check which version it is.
> I don't get it - the COPR has dnf 4 (and all the Rawhide builds failed), not dnf 5 or dnf5. Sorry about that, I included the wrong link, here is the correct COPR: https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/ > Will the new binary always be called "dnf5"? Or is it going to be called "dnf"? We intend to have "dnf" refer to DNF 5 going forward, and the preferred way to call DNF 5 will be /usr/bin/dnf rather than /usr/bin/dnf5. But /usr/bin/dnf5 will always be around to call DNF 5 explicitly to differentiate it from DNF 4. And yes, DNF 5 is not fully backwards-compatible. To support both DNF 4 and DNF 5 at the same time, my suggestion is to change your spec file to conditionally depend on python3-dnf for versions of Fedora <= 38, and depend on dnf5 in newer versions: ``` %if 0%{?fedora} <= 38 Requires: python3-dnf %else Requires: dnf5 %endif ``` Then at runtime, call /usr/bin/dnf5 if it exists, and if not, fall back to the old DNF 4 at /usr/bin/dnf-3.
Richard if you discover anything that blocks you with DNF5 adoption, please don't hesitate to open the issue on our upstream - https://github.com/rpm-software-management/dnf5/issues.
I filed these bugs for missing features: https://github.com/rpm-software-management/dnf5/issues/580 https://github.com/rpm-software-management/dnf5/issues/581
Upstream fix: https://github.com/libguestfs/supermin/commit/92d5d7e8c27088fa3fb8e5e6e9c5b8d3209053d6
What about this: BuildRequires: dnf-plugins-core Should it be changed (eg. "dnf5-plugins-core") or removed?
So dnf5-plugins exists, apparently containing the sub-commands "builddep", "copr" and "repoclosure" (we only need "dnf download"). dnf5 seems to contain the dnf download command. So my guess is removing this line is the right thing.
FEDORA-2023-d1afba9ba3 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d1afba9ba3
FEDORA-2023-d1afba9ba3 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
Correct, yes the download command is part of dnf5 now, not dnf5-plugins.
This change causes the following problem: https://bugzilla.redhat.com/show_bug.cgi?id=2211386