How To use dnf (any branch of OM Lx)

Tags: #<Tag:0x00007fe31b5bd7a8> #<Tag:0x00007fe31b5bd668> #<Tag:0x00007fe31b5bd4d8> #<Tag:0x00007fe31b5bd398>

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:

$ sudo dnf clean all

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

To update your system from command line:

$ sudo dnf 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.

Know it, learn it, believe it, use it.



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.

1 Like

Very useful to have some common commands at hand.

1 Like

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.

1 Like

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>*

1 Like

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
1 Like