How To use dnf (any version of OM Lx)

Note: This post is approximately a 4 minute read. Perhaps longer for someone for whom English is not their native language.

Note: For most OM Lx Rock or OM Lx Rolling users this first post provides more than enough to do your package management and system upgrades from command line (Konsole or terminal).

Among the changes in OM Lx 4.0 is switching from urpmi/ to dnf/ For most of us users we don’t need to be concerned about the rpm part that is just different versions of rpm and maintained by different people, this will affect developers but users likely won’t notice anything different. The change from urpmi to dnf will be noticed by users as the commands will be different.

The not so secret about package management in Linux is the Package Management GUI’s can take longer to learn and get used to than the command line interface (cli). The simplest thing is to open Konsole and type:

$ dnf --help


$ man dnf

The help menu takes about a minute to a minute and a half to read. The man page takes about 3-5 minutes. Both are meant to be available for users to refer to as they use their system and need to find quickly how to do something. There are also wiki pages and docs about dnf. Using the DNF software package manager. Fedora wiki page. DNF Command Reference. Most users don’t really need to read these maybe just scan while you are getting used to dnf and know the links are available when you need to look something up. Same applies to --help menu and man pages, just scan them and know they are there if you need them.

Some basics for using dnf in OpenMandriva Lx 4.0:

To install a package:

$ sudo dnf install packagename

To remove a package:

$ sudo dnf remove packagename

To search repositories for a package:

$ sudo dnf search packagename

Note: I find that ‘dnf search’ will work with partial names as well which should make it lots easier to find

To cleanup any files and packages left in cache and to remove repository metadata:

$ dnf clean all ; sudo dnf clean all

this will force dnf to download fresh metadata next time dnf is run.

To update your Rock system from command line:

$ dnf clean all ; sudo dnf clean all ; sudo dnf upgrade

Rock systems will automatically get switched to new repositories when a new stable version of OM Lx is released. For this upgrade you need the distribution upgrade command dnf distro-sync. We will announce this in the Forum and include any special instructions users need for that particular distribution upgrade. The distribution upgrade command is:

$ dnf clean all ; sudo dnf clean all ; sudo dnf distro-sync

To upgrade your Rolling system use the distribution upgrade command:

$ dnf clean all ; sudo dnf clean all ; sudo dnf distro-sync

This is used in Rolling for technical reasons. At appropriate times OM developers copy Cooker repositories to Rolling repositories. So basically the same as when Rock repositories are changed form say OM Lx 4.1 to OM Lx 4.2. When this happens there are new distro-release packages which makes distro-sync necessary to pick up the new package list for that version. We will announce this in the Forum and include any special instructions users need for that particular distribution upgrade.

Some other common dnf commands:

autoremove - removes packages installed as dependencies that are no longer required by currently installed programs.

check-update - checks for updates, but does not download or install the packages.

downgrade - reverts to the previous version of a package.

info - provides basic information about the package including name, version, release, and description.

reinstall - reinstalls the currently installed package.

repolist - simply list enabled repositories.

Some dnf commands may be abbreviated:

dnf in=dnf install
dnf ri=dnf reinstall
dnf dg=dnf downgrade
dnf rm=dnf remove
dnf up=dnf upgrade
dnf dsync=dnf distro-sync

I’ll add a few more helpful things as time passes. Like:

$ sudo dnf autoremove

is similar to:

$ sudo urpme --auto-orphans

Be careful and pay attention when using ‘dnf autoremove’ It is absolutely possible that this may remove something you don’t want to remove. It is a good idea to keep a list of packages that were autoremoved so you know what to install if this happens. Note: (You can find autoremoved packages in /var/log/dnf.log.)


There is an option to download packages only and then user can install them at a later time:

$ sudo dnf --downloadonly upgrade
DNF will only download packages for the transaction.
Is this ok [y/N]:

This is very helpful for users with troublesome or slow internet connection. You download all package first and then install. Or you can download them and install some other time.


A companion How To for editing dnf repositories is here.


Very useful to have some common commands at hand.


Here a couple of other useful command.

Search a package into (un)installed packages list:

dnf list installed "packagename"
dnf list uninstalled "packagename"

The same with partial packagename

dnf list installed "packagename*"
dnf list uninstalled "*packagename"

Get the history of dnf (with all operation done):

$ sudo dnf history 

Get the history of latest packages installed by the user:

$ sudo dnf history userinstalled


Yes, some very useful commands there.


This is a very important one for command line users:

How do you mark a package so ‘dnf autoremove’ will not remove it?

$ sudo dnf mark install <package_name>

Again reminder that at this stage of “newness” with dnf in OpenMandriva I would recommend to be very careful with ‘dnf autoremove’. Of course it is fundamentally stupid with any package manager to ever use an --auto-orphans or autoremove type function without checking the list and if there is even the slightest doubt don’t do it until you ask someone more knowledgeable.

Full Disclosure: Have I ever done anything stupid in Linux? I decline to answer that question on the grounds that it will make me look really dumb.



Here some other dnf commands used to get informations about package. It does not mater if the package is installed or not because all infos are taken from repository metadata.

Show list of files in the package (the same as urpmq -i <pkgname>)

dnf repoquery --info <pkgname>
dnf repoquery -i <pkgname>

Display capabilities provided by the package (the same as urpmq -l <pkgname>)

   dnf repoquery --list <pkgname>
   dnf repoquery -l <pkgname>

Shows results that requires package provides and files (the same as urpmq --whatrequires `)

dnf repoquery --whatrequires <pkgname>

Display capabilities that the package depends on (the same as urpmq --requires <pkgname>)

dnf repoquery --requires <pkgname>

Display capabilities provided by the package (the same as urpmq --provides <pkgname>)

dnf repoquery --provides <pkgname>

So dnf repoquery is in some way a replacement of the old urpmq but it is really more powerful: more useful optional arguments about repoquery can be found at official documentation.


Also dnf repoquery may be used to search into installed packages in a similar way as dnf list installed described before but the output is a bit different:

dnf repoquery --installed
dnf repoquery --installed *<pkgname>
dnf repoquery --installed <pkgname>*


When you build a package from .spec you have to install all dependencies (as listed in BuildRequires fileds into the .spec file itself) before, of course, but it is a boring task also because it is usual (and there are some practical reason for this) to refers at a package by mean of something it provides (pkgconfig(…), python3egg(…)_, etc …) instead of the real package name

The package manager is able to make this in one command (the same as sudo urpmi --buildrequires pkgname.spec):

sudo dnf builddep pkgname.spec