How To use dnf (any version of OMLx)

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

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

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

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

and:

$ 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 All branches:

To install a package:

$ sudo dnf in package_name

To remove a package:

$ sudo dnf rm package_name

To upgrade an individual package:

$ sudo dnf up package_name

You can also do multiple packages separated by a space, for example:

$ sudo dnf command package_name package_name package_name package_name

To search repositories for a package:

$ sudo dnf search package_name

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

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. Also after running clean all the next dnf command (like up, dsync, in, rm, autoremove) will list active repositories as it refreshes them.

To update your Rock system from command line it is wise to first run sudo dnf clean all:

$ sudo dnf clean all ; sudo dnf up

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

$ sudo dnf clean all ; sudo dnf dsync

Or sometimes we will need to use the --allowerasing option when things like package names are changed by developers.

$ sudo dnf clean all ; sudo dnf --allowerasing dsync

To upgrade your ROME (rolling) system use the distribution upgrade command again it is wise to first run sudo dnf dsync:

$ sudo dnf clean all ; sudo dnf dsync

This is used in ROME (rolling) for technical reasons. At appropriate times OM developers copy Cooker repositories to ROME (rolling) repositories. So basically the same as when Rock repositories are changed form say OMLx 5.0 to OMLx 5.1. When this happens there are new distro-release packages which makes dsync 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.

User information: Some of the commands above are actually 2 linked commands run in sequence. The sequence does matter. In the above examples we used the semicolon [;] to link 2 or more commands. Some folks use && instead. If you wish to know more about this do an internet search.

If you should have any questions about the material presented here please make a post with a descriptive title in one of our Support forums or contact the contributor team at OpenMandriva Chat. Do not forget that you can do internet search when you have problems with your OMLx system.

6 Likes

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

To mark packages as user installed so autoremove knows not to remove them;

$ sudo dnf mark in package_name

To unmark such packages:

$ sudo dnf mark rm package_name

######################################################################################

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

$ sudo dnf --downloadonly up

 DNF will only download packages for the transaction.
 Is this ok [y/N]:

Or you can use that with dsync. 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.

If you should have any questions about the material presented here please make a post with a descriptive title in one of our Support forums or contact the contributor team at OpenMandriva Chat. Do not forget that you can do internet search when you have problems with your OMLx system.

3 Likes

A companion How To for editing dnf repositories is here.

2 Likes

Very useful to have some common commands at hand.
Thanks!

2 Likes

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
4 Likes

:+1:

Yes, some very useful commands there.

2 Likes

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.

2 Likes

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

2 Likes

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
2 Likes