-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for DNF 5 #214
Comments
With dnf5, there's a new dnfdaemon implementation provided by |
Fedora Rawhide (aka F39) switched to DNF5 now, resulting in Dnfdragora just opening and closing the main window again. |
will see if i can work on it. But i need to work on a fedora virtual machine first... |
Hi, as you may be aware, the switch to DNF 5 has been postponed, likely to Fedora 41. In Fedora 39, the In the meantime, we have set up a testing COPR repository that provides a version of DNF 5 that obsoletes DNF 4. It can be used to test software in an environment similar to the future release of Fedora (whichever that will be) when DNF 5 replaces DNF 4:
Enabling the COPR and upgrading your system should replace DNF 4 (the |
Thanks for the news, since I'm not a daily Fedora user I was not aware of that. |
@evan-goode Is there a Python client for the dnfdaemon implementation included in DNF 5 that we can use to migrate dnfdragora to? |
AFAIK no, we just have the C++ dnf5daemon client at the moment. |
Could you please point me to dnfdaemon api and the c++ client source code? |
Ok API should be here |
Looks like the group tag was missing in the dnf5daemon API, so I submitted a pull request to add it: rpm-software-management/dnf5#1122 |
This is in progress in the |
Just a heads-up, 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 |
Well our master is moved to dnf5daemon for the most, i need to fix some signals code and all should be in iirc. Anyway in my opinion dnf5daemon is not good (or let's say mature) enough to move to it. I had some crashes here and there because of requests lasting too long, and some old dnf 4 daemon features missing, especially to understand when a transaction ends. |
I hope this is just for RedHat. I say let RedHat users be the guinea pigs and let those of us on other distros wait until the flood of bug reports that are introduced by the switch are fixed. (It's my understanding that dnfdragora is a Mageia thing that just happens to also be available on RedHat, not the other way around.) |
dnfdragora is not a Mageia thing, i just developed it there as a mageia user and contributor. |
a dnfdragora 3.0.0 preview has been released, please test it |
(I'm filing issues with all the packages that currently depend on
dnf
)Starting in Fedora 39, the
dnf
command will be provided by thednf5
package rather than thednf
package, anddnf5
will obsoletednf
. The old DNF 4 Python API will still be provided bypython3-dnf
, as well as the DNF 4 command, as/usr/bin/dnf-3
.To avoid breaking the Fedora upgrade, dnfdragora should switch to depending on
python3-dnf
rather thandnf
.And since
/usr/bin/dnf
will soon point to DNF 5, which has a slightly different command-line interface, any use of the/usr/bin/dnf
binary should be replaced with calls to/usr/bin/dnf-3
.At some point, this project should consider a rewrite to adopt libdnf5, but the immediate issue is removing the dependency on
dnf
.For more information about the switch to DNF 5, see https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5.
The text was updated successfully, but these errors were encountered: