Leap 15.2 with dnf?

Hi, was reading Leap 15.2 docs https://en.opensuse.org/Features_15.2 and found that has dnf package manager, some time ago I leave Fedora (30 for its end of life changing to Leap 15.1) and this is a great new, 15.2 will operate with both dnf and zypper? :question:

Yes, “dnf” is there if you want to install it. I assume that it works well. However, “zypper” is likely to be better maintained and supported on openSUSE systems.

And of course, when you run into problems, people here will have experience with Zypper and YaST > Software. Not often with other ways of life. :wink:

Zypper is a major advantage openSUSE has over Fedora. It has one man page instead of a man page for every one of ten bazllion plugins without index to which is applicable for any particular scenario. e.g., compare:

dnf config-manager --set-disabled <reponame>


zypper dr <reponame>

Roughly half the keystrokes.

Zypper has locks that can be overridden/ignored per invocation instead of a configfile that makes packages invisible or not and needs editing each time the locking function needs to be flipped. A simple switch produces search results that are actually sorted. Logically formatted search results include versions, helpful when the only reason for the search is to discover the latest version available, or see if/what older or newer version is available. Zypper readily allows to upgrade a package at a time so that a space-limited / filesystem need not be filled in advance with rpms that prevent upgrade to proceed. DNF is a first class reason to not use Fedora, while Zypper is the best cmdline Gnu Linux package manager existant.

Welcome to openSUSE! :slight_smile:

PS - openSUSE has the best installer too, and best partitioner!


zypper mr -dr <reponame>

A great distro to discover and soon will have the new 15.2 edition. Exciting.

FWIW, I have my own method of managing repos. Every repo I’ve ever used has one or more in-place “backups” originally copied from my LAN server. I disable any repo by removing the .repo file, leaving behind only the “backup”(s), and enable by copying a selected “backup” to .repo. All the backups have uniform timestamps, so whenever one is found to have a non-conformant timestamp, I have something to investigate. e.g., for 15.2, this is one standard group:

ls -Gg OSS*
-rw-r--r-- 1 143 Aug  9  2019 OSS.repo
-rw-r--r-- 1 484 Aug  9  2019 OSS.repoC
-rw-r--r-- 1 143 Aug  9  2019 OSS.repoD
-rw-r--r-- 1 150 Aug  9  2019 OSS.repoE
-rw-r--r-- 1 155 Aug  9  2019 OSS.repoG
-rw-r--r-- 1 147 Aug  9  2019 OSS.repo-gwdg
-rw-r--r-- 1 153 Aug  9  2019 OSS.repoL
-rw-r--r-- 1 147 Aug  9  2019 OSS.repoP
-rw-r--r-- 1 142 Aug  9  2019 OSS.repoW

Each except *D and *C is directed to a specific mirror. *D’s URL is download.opensuse.org. *C includes a specific group of mirror URLs. When I find a current repo to be a problem, I try replacing the troublesome one with another in order to proceed without delay. To add any new repo, I find the appropriate .repo file on a mirror hosting it, save it on the local server, cut its long-winded name down to a smaller size inside & out, sort its content, and save the modified version where it’s wanted. I rarely find a use for most zypper commands, notably mr, most often using ref, al, rl, ll, up, dup, in, rm, se, lr & clean, several via alias or script with switch(es) (e.g. zypse, zypseo, zypsei, zypstart).

I don’t know that anyone anywhere has documented why foreign package managers have been included in openSUSE… I’ve seen yum and even aptitude in openSUSE over the years without explanation.

I wouldn’t recommend using any but zypper and YaST which share a common backend so that everything is tracked properly. If you use any other package manager, at the very least it’ll store its package management info differently which can result in uncaught conflicts. This is generally considered barely tolerable by some for special packages like Python, PHP and Ruby, but even those come with recommendations to reduce conflicts.
Using a package manager like dnf would cause far more problems than what Python, PHP or Ruby might cause.

I’d recommend at least skimming the zypper commands…
You might find it’s not that hard to use after using dnf, keep in mind that some believe that dnf was created in part as a response to seeing how well zypper worked compared to yum.

A few more advanced zypper commands are described in my Wiki, for many people you only need the update, dist-upgrade, install, and “add repository” commands.



If this is true, and I doubt that it is, but if it is, then this is a very bad design. YUM/DNF/etc. are meta-managers that only track package dependencies and leaves the tracking of what is installed to RPM. That’s why both YUM and DNF can be used on RedHat O/Ses at the same time. If Zypper is not doing this, again, bad design.

Based on what proof? Do you know for a fact that Zypper does not use the RPM database for what is installed and instead re-implemented that? I think you have this exactly backwards in fact. I suspect Zypper does use the RPM database, and therefore can interact well with other RPM meta-managers, where as Python, PHP or Ruby package managers are completely invisible to the RPM based managers and so won’t know what each other is doing.

Some believe in Santa Clause and the Easter Bunny. “Some believe” means nothing in terms of proving something. Do you have quotes or other proof from anyone who developed DNF that proves this? If not, please don’t spread “some believe” unsubstantiated rumours.