From Fedora Project Wiki
No edit summary |
m (typo conpared->compared) |
||
| (21 intermediate revisions by 9 users not shown) | |||
| Line 1: | Line 1: | ||
{{autolang|base=yes}} | {{autolang|base=yes}} | ||
DNF is a software package manager that installs, updates, and removes [[package]]s on [[RPM]]-based Linux distributions. It automatically computes dependencies and | '''DNF''' is a software package manager that installs, updates, and removes [[package]]s on [[RPM]]-based Linux distributions. It automatically computes dependencies and determines the actions required to install packages. DNF also makes it easier to maintain groups of machines, eliminating the need to manually update each one using [[rpm]]. Introduced in Fedora 18, it has been the default package manager since Fedora 22. | ||
DNF is the next | DNF or Dandified yum is the next generation version of [[yum]]. It roughly maintains <abbr Title="Command-Line Interface">CLI</abbr> compatibility with [[yum]] and defines a strict <abbr Title="Application Programming Interface">API</abbr> for extensions and plugins. Plugins can modify or extend features of DNF or provide additional <abbr Title="Command-Line Interface">CLI</abbr> commands on top of those mentioned below. If you know the name of such a command (including commands mentioned bellow), you may find/install the package which provides it using the appropriate virtual provide in the form of dnf-command(<alias>) where <alias> is the name of the command; e.g. dnf-command(repoquery) for a repoquery command (the same applies to specifying dependencies of packages that require a particular command). | ||
{{Infobox package | {{Infobox package | ||
| name = DNF | | name = DNF | ||
| package_name = dnf | | package_name = dnf | ||
| package_added = Fedora 18, | | package_added = Fedora 18, and later versions | ||
| website = | | website = https://github.com/rpm-software-management/dnf | ||
}} | }} | ||
== Features == | |||
* Support for multiple repositories | |||
* Simple configuration | |||
* Dependency calculation based on modern depsolving technology | |||
* Faster and less memory-intensive operation | |||
* RPM-consistent behavior | |||
* Package group support, including multiple-repository groups | |||
* Simple interface | |||
* Documented, solid Python API | |||
* DNF runs in both Python 2 and Python 3 | |||
* C bindings for lower level libraries: | |||
** hawkey for package querying and depsolving. PackageKit is already making use of hawkey | |||
** librepo for repo operations. PackageKit is already making use of librepo | |||
** libcomps for comps operations | |||
== Available commands == | == Available commands == | ||
<abbr Title="dnf [options] autoremove Removes all “leaf” packages from the system that were originally installed as dependencies of user-installed packages but which are no longer required by any such package.">autoremove</abbr> | |||
<abbr Title="dnf [options] check [--duplicates] [--obsoleted] [--provides] Checks the local packagedb and produces information on any problems it finds. You can pass the check command the options “--dependencies”, “--duplicates”, “--obsoleted” or “--provides”, to limit the checking that is performed (the default is “all” which does all).">check</abbr> | |||
<abbr Title="dnf [options] check-update [<package-specs>...] Non-interactively checks if updates of the specified packages are available. If no <package-specs> are given checks whether any updates at all are available for your system. DNF exit code will be 100 when there are updates available and a list of the updates will be printed, 0 if not and 1 if an error occurs. Please note that having a specific newer version available for an installed package (and reported by check-update) does not imply that subsequent dnf upgrade will install it. The difference is that dnf upgrade must also ensure the satisfiability of all dependencies and other restrictions.">check-update</abbr> | |||
<abbr Title="Performs cleanup of temporary files for the currently enabled repositories. dnf clean dbcache Removes cache files generated from the repository metadata. This forces DNF to regenerate the cache files the next time it is run. dnf clean expire-cache Removes local cookie files saying when the metadata and mirrorlists were downloaded for each repo. DNF will re-validate the cache for each repo the next time it is used. dnf clean metadata Removes repository metadata. Those are the files which DNF uses to determine the remote availability of packages. Using this option will make DNF download all the metadata the next time it is run. dnf clean packages Removes any cached packages from the system. dnf clean plugins Tells all enabled plugins to eliminate their cached data. dnf clean all Does all of the above.">clean</abbr> | |||
<abbr Title="dnf distro-sync [<package-spec>...] As necessary upgrades, downgrades or keeps selected installed packages to match the latest version available from any enabled repository. If no package is given, all installed packages are considered.">distro-sync</abbr> | |||
<abbr Title="dnf [options] downgrade <package-installed-specs>... Downgrades the specified packages to the highest of all known lower versions if possible. When version is given and is lower than version of installed package then it downgrades to target version.">downgrade</abbr> | |||
<abbr Title="Groups are virtual collections of packages. DNF keeps track of groups that the user selected (“marked”) installed and can manipulate the comprising packages with simple commands. dnf [options] group [summary] <group-spec> Display overview of how many groups are installed and available. With a spec, limit the output to the matching groups. summary is the default groups subcommand. dnf [options] group info <group-spec> Display package lists of a group. Shows which packages are installed or available from a repo when -v is used. dnf [options] group install [with-optional] <group-spec>... Mark the specified group installed and install packages it contains. Also include optional packages of the group if with-optional is specified. dnf [options] group list <group-spec>... List all matching groups, either among installed or available groups. If nothing is specified list all known groups. Records are ordered by display_order tag defined in comps.xml file. dnf [options] group remove <group-spec>... Mark the group removed and remove those packages in the group from the system which are neither comprising another installed group and were not installed explicitly by the user. dnf [options] group upgrade <group-spec>... Upgrades the packages from the group and upgrades the group itself. The latter comprises of installing pacakges that were added to the group by the distribution and removing packages that got removed from the group as far as they were not installed explicitly by the user. Groups can be also be marked installed or removed without physically manipualting any packages: dnf [options] group mark install <group-spec>... Mark the specified group installed. No packages will be installed by this command but the group is then considered installed. dnf [options] group mark remove <group-spec>... Mark the specified group removed. No packages will be removed by this command.">group</abbr> | |||
<abbr Title="dnf help [<command>] Displays the help text for all commands. If given a command name then only displays the help for that particular command.">help</abbr> | |||
<abbr Title="The history command allows the user to view what has happened in past transactions and act according to this information (assuming the history_record configuration option is set). dnf history [list] [<spec>...] The default history action is listing information about given transactions in a table. Each <spec> can be either a <transaction-spec>, which specifies a transaction directly, or a <transaction-spec>..<transaction-spec>, which specifies a range of transactions, or a <package-name-spec>, which specifies a transaction by a package which it manipulated. When no transaction is specified, list all known transactions. dnf history info [<spec>...] Describe the given transactions. The meaning of <spec> is the same as in the History List Command. When no transaction is specified, describe what happened during the latest transaction. dnf history redo <transaction-spec> Repeat the specified transaction. If it is not possible to redo any operation due to the current state of RPMDB, do not redo any operation. dnf history rollback <transaction-spec> Undo all transactions performed after the specified transaction. If it is not possible to undo any transaction due to the current state of RPMDB, do not undo any transaction. dnf history undo <transaction-spec> Perform the opposite operation to all operations performed in the specified transaction. If it is not possible to undo any operation due to the current state of RPMDB, do not undo any operation. dnf history userinstalled List names of all packages installed by a user. The output can be used as the %packages section in a kickstart file. This command by default does not force a sync of expired metadata.">history</abbr> | |||
<abbr Title="dnf [options] info [<package-spec>...] Is used to list description and summary information about available packages. This command by default does not force a sync of expired metadata.">info</abbr> | |||
<abbr Title="dnf [options] install <spec>... Dnf makes sure that the given packages and their dependencies are installed on the system. Each <spec> can be either a <package-spec>, which specifies a package directly, or a path to the local rpm package, or an URL to a remote rpm package, or a @<group-spec>, which specifies an (environment) group which contains it. If a given package cannot be (and is not already) installed, the exit code will be non-zero. Please make sure that you understand which package will be selected in case of multiple matches.">install</abbr> | |||
<abbr Title="Dumps lists of packages depending on the packages’ relation to the system. A package is installed if it is present in the RPMDB, and it is available if it is not installed but it is present in a repository that DNF knows about. The list command can also limit the displayed packages according to other criteria, e.g. to only those that update an installed package. All the forms take a [<package-specs>...] parameter to further limit the result to only those packages matching it. dnf [options] list [all] [<package-name-specs>...] Lists all packages known to us, present in the RPMDB, in a repo or in both. dnf [options] list installed [<package-name-specs>...] Lists installed packages. dnf [options] list available [<package-name-specs>...] Lists available packages. dnf [options] list extras [<package-name-specs>...] Lists extras, that is packages installed on the system that are not available in any known repository. dnf [options] list obsoletes [<package-name-specs>...] List the packages installed on the system that are obsoleted by packages in any known repository. dnf [options] list recent [<package-name-specs>...] List packages recently added into the repositories. dnf [options] list upgrades [<package-name-specs>...] List upgrades available for the installed packages. dnf [options] list autoremove List packages which will be removed by dnf autoremove command. This command by default does not force a sync of expired metadata.">list</abbr> | |||
<abbr Title="dnf [options] makecache Downloads and caches in binary format metadata for all known repos. Tries to avoid downloading whenever possible (e.g. when the local metadata hasn’t expired yet or when the metadata timestamp hasn’t changed). dnf [options] makecache timer Like plain makecache but instructs DNF to be more resource-aware, meaning will not do anything if running on battery power and will terminate immediately if it’s too soon after the last successful makecache run.">makecache</abbr> | |||
<abbr Title="dnf mark install <package-specs>... Marks the specified packages as installed by user. This can be useful if any package was installed as a dependency and is desired to stay on the system when Auto Remove Command or Remove Command along with clean_requirements_on_remove configuration option set to True is executed. dnf mark remove <package-specs>... Unmarks the specified packages as installed by user. Whenever you as a user don’t need a specific package you can mark it for removal. The package stay still installed on the system and will removed when Auto Remove Command or Remove Command along with clean_requirements_on_remove configuration option set to True is executed. You should use this operation instead of Remove Command if your not sure whether the package is a requirement of other user installed package on the system.">mark</abbr> | |||
<abbr Title="dnf [options] provides <provide-spec> Finds the packages providing the given <provide-spec>. This is useful when one knows a filename and wants to find what package (installed or not) provides this file. This command by default does not force a sync of expired metadata.">provides</abbr> | |||
<abbr Title="dnf [options] reinstall <package-specs>... Installs the specified packages, fails if some of the packages are either not installed or not available (i.e. there is no repository where to download the same RPM).">reinstall</abbr> | |||
<abbr Title="dnf [options] remove <package-specs>... Removes the specified packages from the system along with any packages depending on the packages being removed. Each <spec> can be either a <package-spec>, which specifies a package directly, or a @<group-spec>, which specifies an (environment) group which contains it. If clean_requirements_on_remove is enabled (the default) also removes any dependencies that are no longer needed.">remove</abbr> | |||
<abbr Title="dnf [options] repolist [enabled|disabled|all] Depending on the exact command, lists enabled, disabled or all known repositories. Lists all enabled repositories by default. Provides more detailed information when -v option is used. This command by default does not force a sync of expired metadata.">repolist</abbr> | |||
<abbr Title="The repository-packages command allows the user to run commands on top of all packages in the repository named <repoid>. However, any dependency resolution takes into account packages from all enabled repositories. Specifications <package-name-spec> and <package-spec> further limit the candidates to only those packages matching at least one of them. info subcommand lists description and summary information about packages depending on the packages’ relation to the repository. list subcommand just dumps lists of that packages. See detailed description in Command Reference (see bellow)">repository-packages</abbr> | |||
<abbr Title="dnf [options] search [all] <keywords>... Search package metadata for the keywords. Keywords are matched as case-insensitive substrings, globbing is supported. By default the command will only look at package names and summaries, failing that (or whenever all was given as an argument) it will match against package descriptions and URLs. The result is sorted from the most relevant results to the least. This command by default does not force a sync of expired metadata.">search</abbr> | |||
<abbr Title="dnf [options] updateinfo [<output>] [<availability>] [<spec>...] Display information about update advisories. Depending on <output>, DNF displays just counts of advisory types (omitted or summary), list of advisories (list) or detailed information (info). When info with -v option is used, the information is even more detailed. <availability> specifies whether advisories about newer versions of installed packages (omitted or available), advisories about equal and older versions of installed packages (installed), advisories about newer versions of those installed packages for which a newer version is available (updates) or advisories about any versions of installed packages (all) are taken into account. Most of the time, available and updates displays the same output. The outputs differ only in the cases when an advisory refers to a newer version but there is no enabled repository which contains any newer version. If given and if neither ID, type (bugfix, enhancement, security/sec) nor a package name of an advisory does match <spec>, the advisory is not taken into account. The matching is case-sensitive and in the case of advisory IDs and package names, globbing is supported.">updateinfo</abbr> | |||
<abbr Title="dnf [options] upgrade Updates each package to a highest version that is both available and resolvable. dnf [options] upgrade <package-installed-specs>... Updates each specified package to the latest available version. Updates dependencies as necessary.">upgrade</abbr> | |||
<abbr Title="dnf [options] upgrade-to <package-nevr-specs>... Upgrades packages to the specified versions.">upgrade-to</abbr> | |||
== Installation == | == Installation == | ||
DNF comes with Fedora since version 18, but DNF can installed by using the yum Command: | |||
<pre># yum install dnf</pre> | <pre># yum install dnf</pre> | ||
As of Fedora 22, yum has been replaced with | As of Fedora 22, [[yum]] has been replaced with DNF and doesn't need to be installed. | ||
== Usage == | == Usage == | ||
In the basic methods, | In the basic methods, DNF can be used almost exactly as yum to search, install or remove packages: | ||
<pre># dnf search audacity </pre> | |||
<pre># dnf install audacity </pre> | |||
<pre># dnf remove audacity </pre> | |||
=== Automatic Updates === | |||
The DNF-Automatic RPM package as a DNF component provides a service for automatic download and installation of updates. It can automatically monitor and report via email availability of updates, or send a log about downloaded packages and installed updates. See [[AutoUpdates]] section or [http://dnf.readthedocs.org/en/latest/automatic.html DNF-Automatic] page. | |||
=== System Upgrades === | |||
Fedora Products can be upgraded with DNF system upgrade plugin or directly with DNF. See [[Upgrade]] section. | |||
=== Language Support Using DNF === | |||
DNF can be used to install or remove Language Support. A detailed description with a list of available languages can be found on [https://fedoraproject.org/wiki/I18N/Language_Support_Using_Dnf Language Support Using Dnf] page. | |||
=== DNF compared with Apt === | |||
Users coming from Debian or Ubuntu may find this table on [https://fedoraproject.org/wiki/Differences_to_Ubuntu#Package_Management package management comparison] useful. | |||
== Documentation == | == Documentation == | ||
1. [http://dnf.readthedocs.org/ Documentation Index] | 1. [http://dnf.readthedocs.org/ Documentation Index] | ||
2. [http://dnf.readthedocs.org/en/latest/command_ref.html Command Reference] | 2. [http://dnf.readthedocs.org/en/latest/command_ref.html Command Reference] | ||
3. [http://dnf.baseurl.org/ DNF blog] | |||
4. [https://github.com/rpm-software-management/dnf/wiki DNF wiki] | |||
5. [[Changes/DNF-2.0]] | |||
[[Category:Documentation]] | |||
[[Category:Software Management]] | |||
Revision as of 20:15, 5 June 2020
DNF is a software package manager that installs, updates, and removes packages on RPM-based Linux distributions. It automatically computes dependencies and determines the actions required to install packages. DNF also makes it easier to maintain groups of machines, eliminating the need to manually update each one using rpm. Introduced in Fedora 18, it has been the default package manager since Fedora 22.
DNF or Dandified yum is the next generation version of yum. It roughly maintains CLI compatibility with yum and defines a strict API for extensions and plugins. Plugins can modify or extend features of DNF or provide additional CLI commands on top of those mentioned below. If you know the name of such a command (including commands mentioned bellow), you may find/install the package which provides it using the appropriate virtual provide in the form of dnf-command(<alias>) where <alias> is the name of the command; e.g. dnf-command(repoquery) for a repoquery command (the same applies to specifying dependencies of packages that require a particular command).
| DNF | |
| |
| RPM package | dnf
|
| Added in | Fedora 18, and later versions |
| Website | https://github.com/rpm-software-management/dnf |
| Bugs • Bodhi • Koji | |
Features
- Support for multiple repositories
- Simple configuration
- Dependency calculation based on modern depsolving technology
- Faster and less memory-intensive operation
- RPM-consistent behavior
- Package group support, including multiple-repository groups
- Simple interface
- Documented, solid Python API
- DNF runs in both Python 2 and Python 3
- C bindings for lower level libraries:
- hawkey for package querying and depsolving. PackageKit is already making use of hawkey
- librepo for repo operations. PackageKit is already making use of librepo
- libcomps for comps operations
Available commands
autoremove
check
check-update
clean
distro-sync
downgrade
group
help
history
info
install
list
makecache
mark
provides
reinstall
remove
repolist
repository-packages
search
updateinfo
upgrade
upgrade-to
Installation
DNF comes with Fedora since version 18, but DNF can installed by using the yum Command:
# yum install dnf
As of Fedora 22, yum has been replaced with DNF and doesn't need to be installed.
Usage
In the basic methods, DNF can be used almost exactly as yum to search, install or remove packages:
# dnf search audacity
# dnf install audacity
# dnf remove audacity
Automatic Updates
The DNF-Automatic RPM package as a DNF component provides a service for automatic download and installation of updates. It can automatically monitor and report via email availability of updates, or send a log about downloaded packages and installed updates. See AutoUpdates section or DNF-Automatic page.
System Upgrades
Fedora Products can be upgraded with DNF system upgrade plugin or directly with DNF. See Upgrade section.
Language Support Using DNF
DNF can be used to install or remove Language Support. A detailed description with a list of available languages can be found on Language Support Using Dnf page.
DNF compared with Apt
Users coming from Debian or Ubuntu may find this table on package management comparison useful.
Documentation
3. DNF blog
4. DNF wiki