Bug 2209412
| Summary: | supermin, supermin-devel: prepare for DNF 5, don't depend on `dnf` | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Evan Goode <egoode> |
| Component: | supermin | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | rjones |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | supermin-5.3.3-6.fc39 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-05-30 09:52:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2166026 | ||
|
Description
Evan Goode
2023-05-23 19:43:03 UTC
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 |