As it seems, the community wants to replace Zypper with DNF1. As the maintainer of the DNF package manager for openSUSE, I'd like to extend my support of that proposal and also provide a concrete set of benefits to switching from Zypper to DNF.
DNF supports virtually all the same functions as Zypper. Off the top of my head, there are only two major functions that are missing: sticky vendors and soft locks. Both of these features are planned to be implemented soon, with code for sticky vendors being written and reviewed right now3.
The biggest major benefit of DNF is that it is designed to be integrated with. DNF provides a well-documented Python API2 for applications to build on top of and for plugins to extend DNF itself. While the C/C++ API is not yet stable, this is expected to change by the end of the year with the DNF version 5 development.
DNF is also more robust than Zypper, due to its architecture avoiding the need to subprocess to run critical functions (processing repository metadata, installing packages, etc.). Consequently, DNF supports the latest RPM features better than Zypper does currently. For example, Zypper's method of installing packages using the rpm binary prevents it from being able to execute transaction file triggers4, which has blocked efforts to simplify packaging in openSUSE and remove boilerplate that Fedora, Mageia, and other distributions have already successfully executed on. DNF's usage of libsolvext instead of the repo2solv program also means that it isn't subject to processing a potentially brittle command line interface. While it can't yet download metadata in parallel (this is being fixed for DNF 5), it can download packages in parallel.
DNF's other "silent killer feature" is the transaction tracking database, which lets users review transactions and do actions on them. For example, an older transaction can be looked up and then DNF can be told to undo it. Or redo it! This is very powerful when you may need to install stuff temporarily and then clean up perfectly afterwards. Or alternatively, you accidentally installed stuff you did not want and you want to remove it completely. And while SUSE Linux distributions have Btrfs snapshots with snapper (and DNF integrates with that!), it's not always a question of filesystem rollback for this sort of thing. This makes it easy to do actions without triggering file system transitions.
And of course, as you know, DNF offers several quality-of-life enhancements. For example, it has a subcommand that lets you do advanced searching and querying of repositories. This facility makes it easier to discover and leverage content in package repositories. It also lets you install packages by referencing files contained in them, since it loads file lists from repository metadata and computes dependencies for that fully. There's also subcommands available for triggering offline updates from the command-line as well as a straightforward mechanism to do relatively safe system release upgrades combined with the offline updates mechanism.
In terms of project sustainability, Red Hat currently employs a team of six people to work on the DNF package manager. This includes the design, development, and maintenance of all technologies associated with the DNF package manager. This includes the Fedora Modularity5 technology which is in the process of evolving to better adapt to the community's needs. The DNF team has generally been open to accepting outside members to collaborate on the project directly. For example, I have done a significant check of the code review and merging, as well as contributions and maintenance to various parts of the DNF package manager stack. I fully expect that folks from SUSE interested in contributing to DNF would be welcomed with open arms.
In terms of project community interaction, the DNF team hosts a monthly community meeting on the first Friday of every month where various stakeholders help develop the roadmap and give feedback on the current progress. Members from SUSE already participate in these meetings. Marcus Schaefer and David Cassany from the Public Cloud team have been attending for at least a year, and Richard Brown from the Future Technologies team has been joining the meetings since last fall.
Today, DNF has been adopted by a number of Linux distributions. Obviously, you're aware of Fedora and Red Hat Enterprise Linux, but you may not know that it was also adopted by Yocto, Wind River, Mageia, OpenMandriva, ROSA, OpenMamba, and openEuler. There is a broad ecosystem of users and developers around the DNF package manager, which has led to tools like dnfdragora6 being developed by the Mageia project, among others.
DNF has been packaged in openSUSE for three years now7, and has been available for openSUSE Leap and SUSE Linux Enterprise since 15.08. I think it would definitely be possible to introduce it as a tech preview within SLE/Leap 15.x where we can take the time to implement extensions we need in DNF for the SUSE ecosystem, such as SCC support and a dedicated subcommand for supporting migrating back and forth between Leap and SLE, and make it the primary, fully supported package manager for 16.0.
Synced from jsc#OPENSUSE-3.
Metadata Update from @Pharaoh_Atem: - Custom field SUSE Jira adjusted to https://jira.suse.com/browse/OPENSUSE-3
Current status of things:
rpm-repos-openSUSE
Metadata Update from @Pharaoh_Atem: - Issue tagged with: SLE-Ack-Pending
Metadata Update from @Pharaoh_Atem: - Issue set to the milestone: ALP (was: Next)
The discussion highlights from the meeting on July 7th.
Frederic: What are we getting? We could get extra maintainers for the packaging stack (faster development of features). Lubos mentioned parallel fetch in microdnf which speeds up significantly installation, Michael confirmed that this is on the roadmap for zypper, and will be backported to SLE-15.
Are we interested in DNF dbus integration (replacement for packagekit)?
Frederic mentioned that we do not need packagekit if we use flatpak directly. So technically for desktop use-case, there is no need to have packagekit.
Thorsten: we have to be 100% compatible with DNF backend (as in zypper execute after or before DNF execution should not break system, zypper, and DNF needs to be aware of each other).
Michael Andres: Embracing DNF community in openSUSE could be done by interchangeable backends.
Lubos: seems like compatibility is the direction we would like to take
Daniel Mach: achieving zypper-dnf compatibility at the application level is hard and would take a long time to implement. It would be better to create a new, shared standard for the package managers defining the following: format and location of the .repo files format and location of "system state" database (an extension to rpmdb? something external?) from which repos the installed packages came were the packages installed by the user or as dependencies? format and location of "history database" this might be an issue, because zypper knows nothing about modules, while dnf knows nothing about patterns etc.
Benjamin Zeller: adding to Daniel's statement: using standards can help us here, implementing those standards in reusable stand alone libraries could give us a possibility to share workload
Just a confirmation that we're not interested in modularity
Benjamin mentioned the libsolv setting might be different, so there might be subtle differences if you switch backends.
Michael: if libsolv would be configured completely differently on SUSE system, ... but who would like to do this.
lkocman: 5 minutes past, should we wrap up and give this discussion as an input for one of the Work Groups:
Lubos will send email to Ancor who is leader for both 1:1 Management and Installation (people from the meeting, will be in cc).
Benjamin mentioned the libsolv setting might be different, so there might be subtle differences if you switch backends. Michael: if libsolv would be configured completely differently on SUSE system, ... but who would like to do this.
DNF on openSUSE uses mostly the same solver settings as Zypper, because most of those settings are configured at compile-time by libsolv. The main difference between Zypper and DNF is that DNF uses the yumobsoletes behavior and Zypper doesn't. But that could be changed for SUSE systems. On Mandriva systems, DNF turns on urpmreorder, so we could turn off yumobsoletes on SUSE systems.
yumobsoletes
urpmreorder
Daniel Mach: achieving zypper-dnf compatibility at the application level is hard and would take a long time to implement. It would be better to create a new, shared standard for the package managers defining the following: format and location of the .repo files format and location of "system state" database (an extension to rpmdb something external?) from which repos the installed packages came were the packages installed by the user or as dependencies? format and location of "history database" this might be an issue, because zypper knows nothing about modules, while dnf knows nothing about patterns etc.
Insofar as defining those standards you're asking for, this is an extremely hard path to go down. It'd be easier to teach DNF the few things it doesn't know that Zypper knows (patterns and hardware dependencies) than teach Zypper what DNF knows (modules, comps groups, history, etc.).
If you want to make the Zypper CLI work with libdnf, that's certainly an option and Daniel Mach knows that API and could help pull it off.
Meh. You don't have to use it.
I think you're going to be surprised how much the openSUSE community doesn't want to do "all-Flatpak", so not having PK is going to become a problem.
They're as aware as they need to be now. Swapping between the two works fine as long as they're using the same repository definitions and those repo files are configured properly. Zypper could be adjusted to use the repo files installed by rpm-repos-openSUSE-{Leap,Tumbleweed} or DNF can be pointed to the ones YaST generated with libdnf-repo-config-zypp.
rpm-repos-openSUSE-{Leap,Tumbleweed}
libdnf-repo-config-zypp
As long as the repos are in sync, there's nothing really to worry about. DNF handles when packages are not installed by it fairly well, because it needed to when it was replacing YUM, URPMI, Smart, and other package managers.
Thanks for input Neal!
I did speak to Neal Gompa and he mentioned that what we are currently missing to be able to swap backends within various places distribution is specifically
yast dnf backend and suseconnect-ng backend. Rest seems to be already possible.
So the plan is to use the original text as business case and have two jiras for scc and, yast instead of this one. As I don't see easy acceptance criteria for this particular request.
yast https://github.com/yast/yast-packager/issues/622 suseconnect-ng https://github.com/SUSE/connect-ng/issues/145
What about DNF5?
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
We can also expect that DNF will have only limited support from upstream. ... In DNF4 not all configuration is honored by PackageKit and Microdnf
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf
Metadata Update from @lkocman: - Issue set to the milestone: 16.0 (was: ALP)
TBD: let's document what we'd like to have in ALP. I did invite DNF team to the openSUSE conference 2023. I think we could discuss the plans in there.
Login to comment on this ticket.