Mailinglist Archive: opensuse-factory (435 mails)

< Previous Next >
Re: [opensuse-factory] Replacing libzypp stack with libdnf stack
Hi all,

(the following is my personal opinion/view)

Carson Black <uhhadd@xxxxxxxxx> writes:

Lately, I've become somewhat displeased by a lot of shortcomings of
the libzypp stack in regards to how it serves openSUSE.

In condensed list form, my complaints are:
- zypp using external binaries for tasks (rpm, repo2solv) causes
updates that change those binaries to be be particularly unstable

Especially zypper subprocessing to call rpm is downright dangerous and
caused a few issues when the database format of rpmdb changes (does not
happen often, but we've had a recent one from BDB to NDB).

- zypp upgrading is unstable when curl is being updated (from what I
can remember this is because it uses private libcurl APIs that don't
have any stability guarantees)
- lack of parallel downloading of packages and repository metadata
(even libalpm has this now)
- PackageKit backend is extremely subpar (it's the only backend out of
ten or so that doesn't support cancelling transactions)
- nonexistence of a useful and well-documented plugin interface for zypper
- difficult to use from a variety of programming languages as most
bindings are broken and unsupported
- the C++ API itself is a mess, exposing a ton of implementation
details such as the XML parser in public API

I do agree with all of these. Also zypper lacks an equivalent of
`dnf repoquery` which I use so frequently, that I have switched to using
dnf 99% of the time (the remaining 1% is occasional kernel updates, see


Any thoughts/objections regarding the possibility of replacing the
libzypp stack in openSUSE with the libdnf stack?

I see currently one technical blocker: zypper has some special handling
built in when it comes to kernel updates, that dnf does not have. This
combined with the kernel's self-obsoletion [1] causes occasional issues
on upgrades with dnf (dnf will not be able to update the
kernel). However, this should be fixable by removing the self-obsoletion
from the kernel's spec file.

Well, and then there's the elephant in the room: dnf is a Fedora (and
thus a RedHat) product, while zypper is SUSE's child. Just because of
that it's going to be a rocky road and it will probably take ages or be
downright impossible to push dnf as the default to SLE (zypper has a lot
of SLE specific handling, for example packagehub integration).

While I _personally_ would love to have dnf as the default on
Tumbleweed, I'm afraid it's going to be very hard to even push it to
become an equal to zypper. That does not mean that we shouldn't try



[1] see and if you are
interested in further details.

Dan Čermák <dcermak@xxxxxxxx>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nuremberg

(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer
< Previous Next >