DNF es el administrador de paquetes de The Fedora Project que es capaz de consultar información sobre los paquetes, recuperar paquetes de los repositorios, instalar y desinstalar paquetes usando resolución automática de dependencias y actualizar todo el sistema a los últimos paquetes disponibles. DNF lleva a cabo resolución automática de dependencias sobre los paquetes que usted está actualizando, instalando o quitando y de este modo es capaz de determinar, recuperar e instalar todos los paquetes dependientes disponibles. DNF puede ser configurado con repositorios adicionales nuevos, o fuentes de paquetes, y proporciona también muchos plug-ins que mejoran y extienden sus capacidades. DNF es capaz de llevar a cabo muchas de las mismas tareas que RPM; del mismo modo, muchas de las opciones de línea de comandos son similares. DNF habilita una administración de paquetes sencilla y fácil sobre una única máquina o un grupo de ellas.
Administración segura de los paquetes con los paquetes con firma GPG
DNF proporciona una administración de paquetes segura habilitando la firma de verificación GPG (Guardia de Privacidad Gnu; también conocida como GnuPG) sobre paquetes firmados GPG que se activarán para todos los repositorios de paquetes (fuentes de paquete) o para repositorios concretos. Cuando está habilitada la verificación de firma, DNF rehusará instlar cualquier paquete que no tenga la firma GPG con la clave correcta para ese repositorio. Esto significa que usted puede confiar en que los paquetes RPM que usted descarga e instala en su sistema vienen de una fuente de confianza, como The Fedora Project, y no han sido modificados durante la transferencia. Vea en Configurando DNF y los Repositorios DNF detalles sobre como configurar la comprobación de firma con DNF o Comprobación de firmas de paquetes para información sobre el trabajo con y la verificación de paquetes RPM firmados GPF en general.
DNF también le habilita para configurar fácilmente sus propios repositorios de paquetes RPM para la descarga e instalación sobre otras máquinas.
Aprender DNF es una inversión que vale la pena porque es con frecuencia la forma más rápida de llevar a cabo tareas de administración del sustema y proporciona capacidades más allá de las que proporciona la herramienta gráfica de administración de paquetes PackageKit.
DNF y los privilegios de superusuario
Usted debe tener privilegios de superusuario para usar el comando dnf para instalar, actualizar o quitar paquetes de su sistema. Todos los ejemplos de este capítulo asumen que usted tiene ya privilegios de superusuario usando los comandos su o sudo.
Comprobando y Actualizando Paquetes
Checking For Updates
The quickest way to check for updates is to attempt to install any available updates by using the dnf upgrade command as follows:
~]# dnf upgrade Last metadata expiration check performed 1:24:32 ago on Thu May 14 23:23:51 2015. Dependencies resolved. Nothing to do. Complete!
Note that dnf upgrade installs only those updates that can be installed. If a package cannot be updated, because of dependency problems for example, it is skipped.
The dnf check-update command can be used see which installed packages on your system have new versions available, however it does not mean that they can be successfully installed. This command is therefore mostly useful in scripts and for checking for updated packages that were not installed after running dnf upgrade.
~]# dnf check-update Using metadata from Mon Apr 20 16:34:10 2015 (2:42:10 hours old) python.x86_64 2.7.9-6.fc22 updates python-cryptography.x86_64 0.8.2-1.fc22 updates python-libs.x86_64 2.7.9-6.fc22 updates
The packages in the above output are listed as having updated versions. The line in the example output tells us:
python— the name of the package,
x86_64— the CPU architecture the package was built for,
2.7.9— the version of the updated package,
6.fc22— the release of the updated package,
updates-testing— the repository in which the updated package is located.
You can choose to update a single package, multiple packages, or all packages at once. If any dependencies of the package, or packages, you update have updates available themselves, then they are updated too.
To update a single package, run the following command as
dnf upgrade package_name
For example, to update the python package, type:
~]# dnf upgrade python Using metadata from Mon Apr 20 16:38:16 2015 (2:42:14 hours old) Dependencies resolved. ================================================================== Package Arch Version Repository Size ================================================================== Upgrading: python x86_64 2.7.9-6.fc22 updates 92 k python-libs x86_64 2.7.9-6.fc22 updates 5.8 M Transaction Summary ================================================================== Upgrade 2 Packages Total download size: 5.9 M Is this ok [y/N]:
This output contains:
python.x86_64— you can download and install new python package.
python-libs.x86_64— DNF has resolved that the python-libs-2.7.9-6.fc22.x86_64 package is a required dependency of the python package.
DNF presents the update information and then prompts you as to whether you want it to perform the update; DNF runs interactively by default. If you already know which transactions DNF plans to perform, you can use the
-yoption to automatically answer yes to any questions DNF may ask (in which case it runs non-interactively). However, you should always examine which changes DNF plans to make to the system so that you can easily troubleshoot any problems that might arise.
If a transaction does go awry, you can view DNF’s transaction history by using the dnf history command as described in Working with Transaction History.
Updating and installing kernels with DNF
DNF always installs a new kernel in the same sense that RPM installs a new kernel when you use the command rpm -i kernel. Therefore, you do not need to worry about the distinction between installing and upgrading a kernel package when you use the dnf command: it will do the right thing, regardless of whether you are using the dnf upgrade or dnf install command.
When using RPM, on the other hand, it is important to use the rpm -i kernel command (which installs a new kernel) instead of rpm -u kernel (which replaces the current kernel). See Installing and Upgrading Packages for more information on installing and updating kernels with RPM.
To update all packages and their dependencies, enter dnf upgrade without any arguments:
Preserving Configuration File Changes
You will inevitably make changes to the configuration files installed by packages as you use your Fedora system. RPM, which DNF uses to perform changes to the system, provides a mechanism for ensuring their integrity. See Installing and Upgrading Packages for details on how to manage changes to configuration files across package upgrades.
Packages and Package Groups
You can search all RPM package names and summaries by using the following command:
all to match against descriptions and URLs.
This command displays the list of matches for each term. For example, to list all packages that match "meld" or "kompare", type:
~]# dnf search meld kompare Loaded plugins: langpacks, presto, refresh-packagekit ============================== N/S Matched: meld =============================== meld.noarch : Visual diff and merge tool python-meld3.x86_64 : HTML/XML templating system for Python ============================= N/S Matched: kompare ============================= komparator.x86_64 : Kompare and merge two folders Name and summary matches only, use "search all" for everything.
dnf list and related commands provide information about packages, package groups, and repositories.
All of DNF’s list commands allow you to filter the results by appending one or more glob expressions as arguments. Glob expressions are normal strings of characters which contain one or more of the wildcard characters * (which expands to match any character multiple times) and ? (which expands to match any one character).
Filtering results with glob expressions
Be careful to escape the glob expressions when passing them as arguments to a dnf command, otherwise the Bash shell will interpret these expressions as pathname expansions, and potentially pass all files in the current directory that match the globs to DNF. To make sure the glob expressions are passed to DNF as intended, either:
DNF searches only package names when using glob expressions. To search for a version of a package, include a dash and part of the version number as follows:
~]# dnf search kernel*-4* Last metadata expiration check performed 2:46:09 ago on Thu May 14 23:23:51 2015. Installed Packages kernel.x86_64 4.0.0-1.fc22 @System kernel.x86_64 4.0.2-300.fc22 @System kernel-core.x86_64 4.0.0-1.fc22 @System kernel-core.x86_64 4.0.2-300.fc22 @System [output truncated]
See Listing all ABRT addons and plug-ins using glob expressions and Listing available packages using a single glob expression with escaped wildcard characters for an example usage of both these methods.
- dnf list glob_expression…
Lists information on installed and available packages matching all glob expressions.Example 1. Listing all ABRT addons and plug-ins using glob expressions
Packages with various ABRT addons and plug-ins either begin with "abrt-addon-", or "abrt-plugin-". To list these packages, type the following at a shell prompt:
~]# dnf list abrt-addon\* abrt-plugin\* Last metadata expiration check performed 0:14:36 ago on Mon May 25 23:38:13 2015. Installed Packages abrt-addon-ccpp.x86_64 2.5.1-2.fc22 @System abrt-addon-coredump-helper.x86_64 2.5.1-2.fc22 @System abrt-addon-kerneloops.x86_64 2.5.1-2.fc22 @System abrt-addon-pstoreoops.x86_64 2.5.1-2.fc22 @System abrt-addon-python.x86_64 2.5.1-2.fc22 @System abrt-addon-python3.x86_64 2.5.1-2.fc22 @System abrt-addon-vmcore.x86_64 2.5.1-2.fc22 @System abrt-addon-xorg.x86_64 2.5.1-2.fc22 @System abrt-plugin-bodhi.x86_64 2.5.1-2.fc22 @System Available Packages abrt-addon-upload-watch.x86_64 2.5.1-2.fc22 fedora
- dnf list all
Lists all installed and available packages.Example 2. Listing all installed and available packages
~]# dnf list all Last metadata expiration check performed 0:21:11 ago on Mon May 25 23:38:13 2015. Installed Packages NetworkManager.x86_64 1:1.0.2-1.fc22 @System NetworkManager-libnm.x86_64 1:1.0.2-1.fc22 @System PackageKit.x86_64 1.0.6-4.fc22 @System PackageKit-glib.x86_64 1.0.6-4.fc22 @System aajohan-comfortaa-fonts.noarch 2.004-4.fc22 @System abrt.x86_64 2.5.1-2.fc22 @System [output truncated]
- dnf list installed
Lists all packages installed on your system. The rightmost column in the output lists the repository from which the package was retrieved.Example 3. Listing installed packages using a double-quoted glob expression
To list all installed packages that begin with "krb" followed by exactly one character and a hyphen, type:
~]# dnf list installed "krb?-*" Last metadata expiration check performed 0:34:45 ago on Mon May 25 23:38:13 2015. Installed Packages krb5-libs.x86_64 1.13.1-3.fc22 @System krb5-workstation.x86_64 1.13.1-3.fc22 @System
- dnf list available
Lists all available packages in all enabled repositories.Example 4. Listing available packages using a single glob expression with escaped wildcard characters
To list all available packages with names that contain "gstreamer" and then "plugin", run the following command:
~]# dnf list available gstreamer\*plugin\* Last metadata expiration check performed 0:42:15 ago on Mon May 25 23:38:13 2015. Available Packages gstreamer-plugin-crystalhd.i686 3.10.0-8.fc22 fedora gstreamer-plugin-crystalhd.x86_64 3.10.0-8.fc22 fedora gstreamer-plugins-bad-free.i686 0.10.23-24.fc22 fedora gstreamer-plugins-bad-free.x86_64 0.10.23-24.fc22 fedora gstreamer-plugins-bad-free-devel.i686 0.10.23-24.fc22 fedora gstreamer-plugins-bad-free-devel.x86_64 0.10.23-24.fc22 fedora [output truncated]
- dnf group list
Lists all package groups.Example 5. Listing all package groups
~]# dnf group list Loaded plugins: langpacks, presto, refresh-packagekit Setting up Group Process Installed Groups: Administration Tools Design Suite Dial-up Networking Support Fonts GNOME Desktop Environment [output truncated]
- dnf repolist
Lists the repository ID, name, and number of packages it provides for each enabled repository.Example 6. Listing enabled repositories
~]# dnf repolist Last metadata expiration check performed 0:48:29 ago on Mon May 25 23:38:13 2015. repo id repo name status *fedora Fedora 22 - x86_64 44,762 *updates Fedora 22 - x86_64 - Updates 0
- dnf repository-packages repo_id list
Lists the packages from the specified repository.Example 7. Listing packages from a single repository
~]# dnf repository-packages fedora list [option] Last metadata expiration check performed 1:38:25 ago on Wed May 20 22:16:16 2015. Installed Packages PackageKit.x86_64 1.0.6-3.fc22 @System PackageKit-glib.x86_64 1.0.6-3.fc22 @System aajohan-comfortaa-fonts.noarch 2.004-4.fc22 @System [output truncated]
The default action is to list all packages available and installed from the repository specified. Add the
installedoption to list only those packages available or installed from the specified repository.
Displaying Package Information
To display information about one or more packages, use a command as follows:
dnf info package_name…
For example, to display information about the abrt package, type:
~]# dnf info abrt Last metadata expiration check: 1:09:44 ago on Tue May 31 06:51:51 2016. Installed Packages Name : abrt Arch : x86_64 Epoch : 0 Version : 2.8.1 Release : 1.fc24 Size : 2.2 M Repo : @System From repo : updates-testing Summary : Automatic bug detection and reporting tool URL : https://abrt.readthedocs.org/ License : GPLv2+ Description : abrt is a tool to help users to detect defects in applications and : to create a bug report with all information needed by maintainer to fix it. : It uses plugin system to extend its functionality.
The dnf info package_name command is similar to the rpm -q --info package_name command, but provides as additional information the name of the DNF repository the RPM package was installed from (look for the
From repo: line in the output). The dnf info command shows only the newest available package if there is a newer version available than the one installed. The dnf repoquery command can show all installed and available packages.
To display information about all available packages, both installed and available from a repository, use a command as follows:
dnf repoquery package_name --info
For example, to display information about the abrt package, type:
~]# dnf repoquery abrt --info Last metadata expiration check: 1:01:44 ago on Tue May 31 06:51:51 2016. Name : abrt Version : 2.8.1 Release : 1.fc24 Architecture: x86_64 Size : 2318452 License : GPLv2+ Source RPM : abrt-2.8.1-1.fc24.src.rpm Build Date : 2016-05-25 08:54 Packager : Fedora Project URL : https://abrt.readthedocs.org/ Summary : Automatic bug detection and reporting tool Description : abrt is a tool to help users to detect defects in applications and to create a bug report with all information needed by maintainer to fix it. It uses plugin system to extend its functionality.
See the dnf repoquery usage statement for more options:
~]$ dnf repoquery -h usage: dnf [options] COMMAND output truncated
DNF allows you to install both a single package and multiple packages, as well as a package group of your choice.
To install a single package and all of its non-installed dependencies, enter a command in the following form:
dnf install package_name
You can also install multiple packages simultaneously by appending their names as arguments:
dnf install package_name package_name…
If you are installing packages on a multilib system, such as an AMD64 or Intel64 machine, you can specify the architecture of the package, as long as it is available in an enabled repository, by appending .arch to the package name. For example, to install the sqlite2 package for
~]# dnf install sqlite2.i586
You can use glob expressions to quickly install multiple similarly-named packages:
~]# dnf install audacious-plugins-\*
In addition to package names and glob expressions, you can also provide file names to dnf install. If you know the name of the binary you want to install, but not its package name, you can give dnf install the path name:
~]# dnf install /usr/sbin/named
dnf then searches through its package lists, finds the package which provides
/usr/sbin/named, if any, and prompts you as to whether you want to install it.
Finding which package owns a file
If you know you want to install the package that contains the
~]# dnf provides "*bin/named" Using metadata from Thu Apr 16 13:41:45 2015 (4:23:50 hours old) bind-32:9.10.2-1.fc22.x86_64 : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server Repo : @System
dnf provides "*/file_name" will find all the packages that contain file_name.
A package group is similar to a package: it is not useful by itself, but installing one pulls a group of dependent packages that serve a common purpose. A package group has a name and a groupid (GID). The dnf group list -v command lists the names of all package groups, and, next to each of them, their groupid in parentheses. The groupid is always the term in the last pair of parentheses, such as
kde-desktop-environment in the following example:
~]# dnf -v group list kde\* cachedir: /var/cache/dnf/x86_64/22 Loaded plugins: builddep, config-manager, copr, playground, debuginfo-install, download, generate_completion_cache, kickstart, needs-restarting, noroot, protected_packages, Query, reposync, langpacks initialized Langpacks plugin DNF version: 0.6.5 repo: using cache for: fedora not found deltainfo for: Fedora 22 - x86_64 not found updateinfo for: Fedora 22 - x86_64 repo: using cache for: updates-testing repo: using cache for: updates not found updateinfo for: Fedora 22 - x86_64 - Updates Using metadata from Thu Apr 16 13:41:45 2015 (4:37:51 hours old) Available environment groups: KDE Plasma Workspaces (kde-desktop-environment)
You can install a package group by passing its full group name (without the groupid part) to group install:
dnf group install group_name
Multi-word names must be quoted.
You can also install by groupid:
You can even pass the groupid, or quoted name, to the install command if you prepend it with an @-symbol (which tells dnf that you want to perform a group install):
For example, the following are alternative but equivalent ways of installing the
KDE Plasma Workspaces group:
~]# dnf group install "KDE Plasma Workspaces" ~]# dnf group install kde-desktop-environment ~]# dnf install @kde-desktop-environment
Similarly to package installation, DNF allows you to uninstall (remove in RPM and DNF terminology) both individual packages and a package group.
To uninstall a particular package, as well as any packages that depend on it, run the following command as
dnf remove package_name…
As when you install multiple packages, you can remove several at once by adding more package names to the command. For example, to remove totem, rhythmbox, and sound-juicer, type the following at a shell prompt:
~]# dnf remove totem rhythmbox sound-juicer
Similar to install, remove can take these arguments:
Removing a package when other packages depend on it
DNF is not able to remove a package without also removing packages which depend on it. This type of operation can only be performed by RPM, is not advised, and can potentially leave your system in a non-functioning state or cause applications to misbehave and terminate unexpectedly. For further information, refer to Uninstalling Packages in the RPM chapter.
You can remove a package group using syntax congruent with the install syntax:
The following are alternative but equivalent ways of removing the
KDE Plasma Workspaces group:
~]# dnf group remove "KDE Plasma Workspaces" ~]# dnf group remove kde-desktop-environment ~]# dnf remove @kde-desktop-environment
Working with Transaction History
The dnf history command allows users to review information about a timeline of DNF transactions, the dates and times on when they occurred, the number of packages affected, whether transactions succeeded or were aborted, and if the RPM database was changed between transactions. Additionally, this command can be used to undo or redo certain transactions.
To display a list of all transactions, as
root, either run dnf history with no additional arguments, or enter the following command:
To display only transactions in a given range, use the command in the following form:
dnf history list start_id..end_id
You can also list only transactions regarding a particular package or packages. To do so, use the command with a package name or a glob expression:
dnf history list glob_expression…
For example, the list of first five transactions may look as follows:
~]# dnf history list 1..4 Using metadata from Thu Apr 16 13:41:45 2015 (5:47:31 hours old) ID | Login user | Date a | Action | Altere ------------------------------------------------------------------------------- 4 | root <root> | 2015-04-16 18:35 | Erase | 1 3 | root <root> | 2015-04-16 18:34 | Install | 1 2 | root <root> | 2015-04-16 17:53 | Install | 1 1 | System <unset> | 2015-04-16 14:14 | Install | 668 E
The dnf history list command produces tabular output with each row consisting of the following columns:
ID— an integer value that identifies a particular transaction.
Login user— the name of the user whose login session was used to initiate a transaction. This information is typically presented in the
Full Name <username>form, however sometimes the command used to perform the transaction is displayed. For transactions that were not issued by a user (such as an automatic system update),
System <unset>is used instead.
Date and time— the date and time when a transaction was issued.
Action(s)— a list of actions that were performed during a transaction as described in Possible values of the Action(s) field.
Altered— the number of packages that were affected by a transaction, possibly followed by additional information.
At least one package has been downgraded to an older version.
At least one package has been removed.
At least one new package has been installed.
At least one package has been marked as obsolete.
At least one package has been reinstalled.
At least one package has been updated to a newer version.
Apart from reviewing the transaction history, the dnf history command provides means to revert or repeat a selected transaction. To revert a transaction, type the following at a shell prompt as
To repeat a particular transaction, as
root, run the following command:
Both commands also accept the
last keyword to undo or repeat the latest transaction.
Note that both dnf history undo and dnf history redo commands merely revert or repeat the steps that were performed during a transaction, and will fail if the required packages are not available. For example, if the transaction installed a new package, the dnf history undo command will uninstall it and also attempt to downgrade all updated packages to their previous version, but the command will fail if the required packages are not available.
Configuring DNF and DNF Repositories
The configuration file for DNF and related utilities is located at
/etc/dnf/dnf.conf. This file contains one mandatory
[main] section, which allows you to set DNF options that have global effect, and may also contain one or more
[repository] sections, which allow you to set repository-specific options. However, it is recommended to define individual repositories in new or existing
.repo files in the
/etc/yum.repos.d/ directory. The values you define in individual
[repository] sections of the
/etc/dnf/dnf.conf file override values set in the
This section shows you how to:
set global DNF options by editing the
[main]section of the
set options for individual repositories by editing the
.repofiles in the
use DNF variables in
/etc/dnf/dnf.confand files in the
/etc/yum.repos.d/directory so that dynamic version and architecture values are handled correctly;
add, enable, and disable DNF repositories on the command line; and,
set up your own custom DNF repository.
Setting [main] Options
/etc/dnf/dnf.conf configuration file contains exactly one
[main] section, and while some of the key-value pairs in this section affect how dnf operates, others affect how DNF treats repositories.
You can add many additional options under the
[main] section heading in
/etc/dnf/dnf.conf configuration file can look like this:
[main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=true
The following are the most commonly-used options in the
…where value is an integer between
10. Setting a higher
debuglevelvalue causes dnf to display more detailed debugging output.
debuglevel=0disables debugging output, and
debuglevel=2is the default.
This option allows you to exclude packages by keyword during installation and updates. Listing multiple packages for exclusion can be accomplished by quoting a space-delimited list of packages. Shell globs using wildcards (for example,
?) are allowed.
…where value is one of:
0— Disable GPG signature-checking on packages in all repositories, including local package installation.
1— Enable GPG signature-checking on all packages in all repositories, including local package installation.
gpgcheck=1is the default, and thus all packages' signatures are checked.
If this option is set in the
[main]section of the
/etc/dnf/dnf.conffile, it sets the GPG-checking rule for all repositories. However, you can also set
gpgcheck=valuefor individual repositories instead; you can enable GPG-checking on one repository while disabling it on another. Setting
gpgcheck=valuefor an individual repository in its corresponding
.repofile overrides the default if it is present in
For more information on GPG signature-checking, refer to Checking Package Signatures.
installonlypkgs=space separated list of packages
Here you can provide a space-separated list of packages which dnf can install, but will never update. See the dnf.conf(5) manual page for the list of packages which are install-only by default.
If you add the
/etc/dnf/dnf.conf, you should ensure that you list all of the packages that should be install-only, including any of those listed under the
installonlypkgssection of dnf.conf(5). In particular, kernel packages should always be listed in
installonlypkgs(as they are by default), and
installonly_limitshould always be set to a value greater than
2so that a backup kernel is always available in case the default one fails to boot.
…where value is an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in the
The defaults for the
installonlypkgsdirective include several different kernel packages, so be aware that changing the value of
installonly_limitwill also affect the maximum number of installed versions of any single kernel package. The default value listed in
installonly_limit=3, and it is not recommended to decrease this value, particularly below
…where value is one of:
0— Do not retain the cache of headers and packages after a successful installation. This is the default.
1— Retain the cache after a successful installation.
For a complete list of available
[main] options, refer to the
[MAIN] OPTIONS section of the dnf.conf(5) manual page.
Setting [repository] Options
[repository] sections, where repository is a unique repository ID such as
my_personal_repo (spaces are not permitted), allow you to define individual DNF repositories.
The following is a bare-minimum example of the form a
[repository] section takes:
[repository] name=repository_name baseurl=repository_url
[repository] section must contain the following directives:
…where repository_name is a human-readable string describing the repository.
…where parameter is one of the following:
…where repository_url is a URL to a directory containing a
repodatadirectory of a repository, a metalink file, or a mirror list file.
If the repository is available over HTTP, use:
If the repository is available over FTP, use:
If the repository is local to the machine, use:
If a specific online repository requires basic HTTP authentication, you can specify your user name and password by prepending it to the URL as
username:password@link. For example, if a repository on http://www.example.com/repo/ requires a username of "user" and a password of "password", then the
baseurllink could be specified as
Usually this URL is an HTTP link, such as:
Note that DNF always expands the
$basearchvariables in URLs. For more information about DNF variables, refer to Using DNF Variables.
To configure the default set of repositories, use the
enabled option as follows:
…where value is one of:
0— Do not include this repository as a package source when performing updates and installs.
1— Include this repository as a package source.
Turning repositories on and off can also be performed by passing either the
--set-disabled repo_nameoption to the dnf command, or through the
Add/Remove Softwarewindow of the PackageKit utility.
[repository] options exist. For a complete list, refer to the
[repository] OPTIONS section of the dnf.conf(5) manual page.
Using DNF Variables
Variables can be used only in the appropriate sections of the DNF configuration files, namely the
/etc/dnf/dnf.conf file and all
.repo files in the
/etc/yum.repos.d/ directory. Repository variables include:
Refers to the release version of operating system which DNF derives from information available in RPMDB.
Refers to the system’s CPU architecture. Valid values for
Refers to the base architecture of the system. For example, i686 and i586 machines both have a base architecture of
i386, and AMD64 and Intel64 machines have a base architecture of
Viewing the Current Configuration
To list all configuration options and their corresponding values, and the repositories, execute the dnf config-manager command with the
~]$ dnf config-manager --dump =============================== main ====================================== [main] alwaysprompt = True assumeno = False assumeyes = False bandwidth = 0 best = False bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf cachedir = /var/cache/dnf/x86_64/22 [output truncated]
Adding, Enabling, and Disabling a DNF Repository
Setting [repository Options] describes various options you can use to define a DNF repository. This section explains how to add, enable, and disable a repository by using the dnf config-manager command.
To define a new repository, you can either add a
[repository] section to the
/etc/dnf/dnf.conf file, or to a
.repo file in the
/etc/yum.repos.d/ directory. All files with the
.repo file extension in this directory are read by DNF, and it is recommended to define your repositories here instead of in
DNF repositories commonly provide their own
.repo file. To add such a repository to your system and enable it, run the following command as
dnf config-manager --add-repo repository_url
…where repository_url is a link to the
To add a repository located at http://www.example.com/example.repo, type the following at a shell prompt:
~]# dnf config-manager --add-repo http://www.example.com/example.repo adding repo from: http://www.example.com/example.repo
To enable a particular repository or repositories, type the following at a shell prompt as
…where repository is the unique repository ID. To display the current configuration, add the
To disable a DNF repository, run the following command as
…where repository is the unique repository ID. To display the current configuration, add the
dnf(8)— The DNF command reference manual page.
dnf.conf(8)— DNF Configuration Reference manual page.
The DNF wiki contains more documentation.
Want to help? Learn how to contribute to Fedora Docs ›