#2870 Change proposal: Replace DNF with DNF5
Opened 14 days ago by bcotton. Modified 3 days ago

Make DNF5 the new default packaging tool. The change will replace DNF, LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library. It is a second step after https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.


Looks like there are still blockers (like that modular filtering is not implemented yet) - should we wait with voting on "make it the new default" until at least the biggest blockers are resolved?

I'd rather approve this for F39 now, with a set of blockers that would mean we trigger the contingency plan.

It would also be super cool if we ship dnf5 in time for Fedora 38 as an opt-in package in the official repo with official support so we can advertise this one release sooner. The current state of dnf5 is unfortunately not presentable as it seems. I am a bit afraid about doing a leap to it without prior heavy testing at least by our contributors.

Agreed on approving this for F39 now. This change needs a lot of runway and likely stages. Better to approve it now and have plenty of time.

+1

I have great hopes for DNF5 and I think it all looks very promising. But I don't think we should "sign off" on a replacement of the default implementation at this point, at least not without much more information. As minimum, the list of dependant packages and various features (dnf-automatic, history, modular filtering, history, graphical interfaces, python interface, etc.) would need to be drawn up, with a clear categorization of what is blocking for the switch, what is "nice to have", and what is not planned. And I think it's the Change Owner who should create such a list, with input from the community, because they have the best understanding of what is needed and what is possible. The list of topics should also include some provision for bugs reported by early users. For example, would perceived regressions in the output be something that'd block the transition? Then, as F39 nears, we can decide if we're close enough to do the switch or if we should wait.

I more or less agree with @zbyszek. My point of view was that we can agree on the plan now, but we need a clear todo-list of what is needed and we don't make the switch if the todo-list is not finished. Not approving at all and working towards the goal works as well.

Either way, I am -1 for now to avoid automatic approval for the proposal AS IS. This does not mean I am against the goal.

Metadata Update from @churchyard:
- Issue tagged with: meeting

4 days ago

I think in order to approve this for f39, we at the very least need to have all the dependencies that we actually use to create and install Fedora ported before we use them to create f39.
(ie, mock, koji, oz/imagefactory, osbuild, releng scripts, pungi, anaconda, lorax, releng/scripts, etc)

I think in order to approve this for f39, we at the very least need to have all the dependencies that we actually use to create and install Fedora ported before we use them to create f39.
(ie, mock, koji, oz/imagefactory, osbuild, releng scripts, pungi, anaconda, lorax, releng/scripts, etc)

And ansible :). Besides the fact that @kevin and I maintain it, ansible is heavily used by Fedora Infra, and it requires python3-dnf for the package/dnf module. Without a functioning package module, it's pretty useless.

The proposal is posted in huge advance to the deadline (beta F39). The approval is supposed to help other teams with planning. Without approval it increases the change that the transition will not have enough attention from other teams. Anyway DNF team is willing to help wit transition. Also we can prioritize delivery of missing parts that blocks transition but we need to know what is not working, missing and so on.

This will be discussed during FESCo meeting today at 17:00 UTC. @jmracek (and anyone else interested) are invited!

I re-read the proposal again, and my conclusion is the same as before: the "Scope" section needs a lot more details.

Sorry, but we've had many tough transitions in Fedora, and one of the things that have been learned is that we need to figure out all the stakeholders (human and programmatic) and plan for each one: fix, drop, replace, or ignore. This makes it easier to avoid surprises and much easier to coordinate work. Once we have a list, we should open bugs against various components and have at least a general idea who will do the work.

Some things to add to Scope:
- ansible
- releng tools that use python3-dnf
- releng tools that call dnf repoquery
- packaging of DNF5 for Fedora. (Can we please do that as soon as possible, possibly with a separate dnf5-unversion-command subpackage so that people can opt-in for testing?)

Who is responsible for integration in PackageKit and dnfdaemon and other graphical interfaces? Do we plan to make them wrappers around Dnf5Daemon? What about pungi/anaconda?

I re-read the proposal again, and my conclusion is the same as before: the "Scope" section needs a lot more details.

Sorry, but we've had many tough transitions in Fedora, and one of the things that have been learned is that we need to figure out all the stakeholders (human and programmatic) and plan for each one: fix, drop, replace, or ignore. This makes it easier to avoid surprises and much easier to coordinate work. Once we have a list, we should open bugs against various components and have at least a general idea who will do the work.

Some things to add to Scope:
- ansible
- releng tools that use python3-dnf
- releng tools that call dnf repoquery
- packaging of DNF5 for Fedora. (Can we please do that as soon as possible, possibly with a separate dnf5-unversion-command subpackage so that people can opt-in for testing?)

Who is responsible for integration in PackageKit and dnfdaemon and other graphical interfaces? Do we plan to make them wrappers around Dnf5Daemon? What about pungi/anaconda?

I am really sorry but I created a confusion in Upgrade/compatibility impact section. The proposal is not about removal of python3-dnf but about what will be called from commandline when dnf command is used.
There is not a conflict between DNF5 and python3-dnf therefore they can coexist. python3-dnf even provide dnf-3 binary therefore some scripts that use repoquery and will be unable to use right now DNF5 they can still in Fedora 39 use alternative binary.
Be honest in future DNF team will stop to support dnf and libdnf for Fedora but it will be subject of another proposal for Fedora 40+. We understand that the transition will be painful therefore we still keep open a window for a longer period, but it will be not opened like it was with yum (Fedora 22 - 31).

I am really sorry but I created a confusion in Upgrade/compatibility impact section. The proposal is not about removal of python3-dnf but about what will be called from commandline when dnf command is used.

Well, it said that python3-dnf would be obsoleted by fedora-obsolete-packages. Now it says that this can optionally happen. Can you please firmly state what's being proposed? A package isn't still available if it's obsoleted.

Also re. compatibility: will dnf system-upgrade work properly if dnf is getting replaced with dnf5 during the update? What will that look like?

There is not a conflict between DNF5 and python3-dnf therefore they can coexist. python3-dnf even provide dnf-3 binary therefore some scripts that use repoquery and will be unable to use right now DNF5 they can still in Fedora 39 use alternative binary.

So those scripts will have to be modified to use dnf-3 repoquery? It seems the old /usr/bin/repoquery alias that dnf-utils currently provides will be removed completely, i.e not provided by either dnf version. As it stands, dnf5 repoquery is missing a large amount of the old functionality.

To be clear, I'm happy about the new dnf5. It fixes multiple longstanding issues! I just don't want it to be soured by a bunch of breakage.

Also re. compatibility: will dnf system-upgrade work properly if dnf is getting replaced with dnf5 during the update? What will that look like?

Also: if the system has both dnf and dnf5 installed, what data will be shared between them? IIUC, the history databases are completely separate, so neither will be aware of transactions done by the other. Can this cause problems where for example dnf will be confused and not know why packages were installed by dnf5? Can we switch back and forth?

I re-read the proposal again, and my conclusion is the same as before: the "Scope" section needs a lot more details.

Sorry, but we've had many tough transitions in Fedora, and one of the things that have been learned is that we need to figure out all the stakeholders (human and programmatic) and plan for each one: fix, drop, replace, or ignore. This makes it easier to avoid surprises and much easier to coordinate work. Once we have a list, we should open bugs against various components and have at least a general idea who will do the work.

Some things to add to Scope:
- ansible
- releng tools that use python3-dnf
- releng tools that call dnf repoquery
- packaging of DNF5 for Fedora. (Can we please do that as soon as possible, possibly with a separate dnf5-unversion-command subpackage so that people can opt-in for testing?)

Who is responsible for integration in PackageKit and dnfdaemon and other graphical interfaces? Do we plan to make them wrappers around Dnf5Daemon? What about pungi/anaconda?

I am really sorry but I created a confusion in Upgrade/compatibility impact section. The proposal is not about removal of python3-dnf but about what will be called from commandline when dnf command is used.
There is not a conflict between DNF5 and python3-dnf therefore they can coexist. python3-dnf even provide dnf-3 binary therefore some scripts that use repoquery and will be unable to use right now DNF5 they can still in Fedora 39 use alternative binary.
Be honest in future DNF team will stop to support dnf and libdnf for Fedora but it will be subject of another proposal for Fedora 40+. We understand that the transition will be painful therefore we still keep open a window for a longer period, but it will be not opened like it was with yum (Fedora 22 - 31).

This was on the agenda for today's meeting, but we run out of time.

Login to comment on this ticket.

Metadata