#1 DNF for SLE and Leap Next
Opened 2 years ago by Pharaoh_Atem. Modified 2 months ago

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.


Metadata Update from @Pharaoh_Atem:
- Custom field SUSE Jira adjusted to https://jira.suse.com/browse/OPENSUSE-3

2 years ago

Current status of things:

  • DNF 4.7.0 and Micro DNF 3.8.0 are landing as updates to Leap 15.3
  • Transactional updates has been ported to Micro DNF and PackageKit with libdnf-plugin-txnupd and is used in Tumbleweed for MicroOS Desktop, with other flavors coming soon
  • rpm-repos-openSUSE provides default repo configuration for DNF on Leap and Tumbleweed
  • Base containers using Micro DNF or DNF are available for both Leap 15.3 and Tumbleweed

Metadata Update from @Pharaoh_Atem:
- Issue tagged with: SLE-Ack-Pending

2 years ago

Metadata Update from @Pharaoh_Atem:
- Issue set to the milestone: ALP (was: Next)

2 years ago

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.

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.).

Michael Andres: Embracing DNF community in openSUSE could be done by interchangeable backends.

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.

Just a confirmation that we're not interested in modularity

Meh. You don't have to use it.

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.

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.

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).

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.

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.

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)

a year ago

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.

I've submitted DNF 5 to Factory and am waiting for all the approvals to get it to land: https://build.opensuse.org/request/show/1134536

Login to comment on this ticket.

Metadata