(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 perl-CPAN-Plugin-Sysdeps 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/dnf5-unstable/, and documentation is available here: https://dnf5.readthedocs.io/en/latest/. - Alternatively, or in the meantime, change the perl-CPAN-Plugin-Sysdeps package 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 perl-CPAN-Plugin-Sysdeps package will break as long as it still depends on the `dnf` package. For more information about the switch to DNF 5, see https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5. Reproducible: Always
Do I understand correctly that dnf5 package will provide /usr/bin/dnf program? In other words, the official interface will be a dependency on dnf5 and execution of dnf? If it is so, adapting perl-CPAN-Plugin-Sysdeps has to wait on the dfn5 change. If I adapted perl-CPAN-Plugin-Sysdeps sooner, it would execute nonexistent "dnf" command because until then dnf5 package won't provide dnf executable.
To explain my question: Should we start telling users and upstreams that instead of executing "dnf" they should execute "dnf5" program?
> Do I understand correctly that dnf5 package will provide /usr/bin/dnf program? In other words, the official interface will be a dependency on dnf5 and execution of dnf? Correct! > Should we start telling users and upstreams that instead of executing "dnf" they should execute "dnf5" program? No, although for a little while, software may want to support both DNF 4 and DNF 5 in the same codebase. The command-line interface between DNF 4 and 5 is slightly different, so it may be desirable to explicitly call /usr/bin/dnf5 in some cases to avoid ambiguity. But the typical command-line user should keep executing `dnf` and hopefully will not even notice much of a difference after /usr/bin/dnf becomes DNF 5. > If it is so, adapting perl-CPAN-Plugin-Sysdeps has to wait on the dfn5 change. If I adapted perl-CPAN-Plugin-Sysdeps sooner, it would execute nonexistent "dnf" command because until then dnf5 package won't provide dnf executable. Yes, the change is not quite yet released to Rawhide; there have been a couple hiccups getting there. What's important is that your package does not depend on `dnf` in Fedora >= 39. An immediate fix would be to depend on `python3-dnf` and call /usr/bin/dnf-3 instead of `dnf`. If you want to implement support for DNF 5, and support DNF 4 and DNF 5 in the same version of the package, I recommend the following: - Add a conditional statement to the spec file to require DNF 4 in Fedora <= 38 and DNF 5 in other versions: ``` %if 0%{?fedora} <= 38 Requires: python3-dnf %else Requires: dnf5 %endif ``` - Then, if your package can use the same command-line invocation to call both DNF 4 and DNF 5, you may not need to change any code, simply keep calling `dnf`. But if some behavior you need has changed since DNF 5, you will need to detect whether the system is using DNF 4 or 5 (you can check whether /usr/bin/dnf5 exists) and call the correct command accordingly, either /usr/bin/dnf5 or, if only DNF 4 is available, /usr/bin/dnf-3. If instead you find that your program needs some behavior that isn't (yet) supported by DNF 5, please file an issue in our upstream bug tracker: https://github.com/rpm-software-management/dnf5/issues. Until it's addressed, you'll want to continue using DNF 4, so you should change any calls to "dnf" in your code to "dnf-3", and change your spec file to depend on python3-dnf instead of dnf in all versions of Fedora. Let me know if you have further questions, I understand it's a confusing situation.
Thanks for confirming DNF5 interface. > What's important is that your package does not depend on `dnf` in Fedora >= 39. That's what I have a problem with. With the time line. > %if 0%{?fedora} <= 38 > Requires: python3-dnf > %else > Requires: dnf5 > %endif > > - Then, if your package can use the same command-line invocation to call both DNF 4 and DNF 5, you may not need to change any code, simply keep calling `dnf`. That's not good advise because on old Fedoras: $ rpm -qf /usr/bin/dnf dnf-4.15.1-1.fc37.noarch and now on F39: # rpm -qf /usr/bin/dnf dnf-4.15.1-1.fc39.noarch In my opinion, the real condition is not "Fedora >= 39". It is "/usr/bin/dnf is provided by dnf5 package". Packagers are not going to change their packages now, and then few weeks later after you make DNF5 default. I guess once dnf5 package provides /usr/bin/dnf5, it will also provide "dnf" RPM symbol. Hence I propose a different approach: Keep packages as they are (invoke /usr/bin/dnf and depend on dnf). Once DNF5 is default, packagers can gradually change the dependency from "dnf" to "dnf5". Preferably before F39 freeze.
> In my opinion, the real condition is not "Fedora >= 39". It is "/usr/bin/dnf is provided by dnf5 package". Packagers are not going to change their packages now, and then few weeks later after you make DNF5 default. Yes, you're right, I should have clarified that those changes will have to wait until DNF 5 provides /usr/bin/dnf. > I guess once dnf5 package provides /usr/bin/dnf5, it will also provide "dnf" RPM symbol. Hence I propose a different approach: Keep packages as they are (invoke /usr/bin/dnf and depend on dnf). Once DNF5 is default, packagers can gradually change the dependency from "dnf" to "dnf5". Preferably before F39 freeze. I think the issue with that is that when DNF 5 takes over /usr/bin/dnf, programs that call the binary could break since the command-line interface will change. So they should immediately switch to calling /usr/bin/dnf-3 and depending on python3-dnf so that they won't sponteneously break, and then later they can figure out support for DNF 5. But yes, I agree, it's awkward to ask maintainers to change their packages twice.
Reverted in perl-CPAN-Plugin-Sysdeps-0.70-11.fc39 because DNF5 is not ready yet. This request will be revisited in Fedora 41.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
The Fedora 41 development cycle is beginning, and we are planning to obsolete DNF 4 by DNF 5 in Fedora Rawhide within the next few weeks. Again, libdnf is not going away, and the old DNF 4 command will still be available as `/usr/bin/dnf-3`, but `/usr/bin/dnf` will be DNF 5, which has a slightly different command-line interface. Packages should no longer depend on the `dnf` package in Fedora 41+.
Thanks for the reminder. I hope you will tell us when dnf5 starts providing /usr/bin/dnf program. Until then I cannot implement this change because this package executes /usr/bin/dnf.