Daniel Mach
Atomic Bot
parent
f589e08324
commit
9ca2a94324
|
|
@ -3,12 +3,12 @@ All files in DNF are distributed as GPLv2+ with the exceptions below:
|
|||
rpm/transaction.py : GPL
|
||||
|
||||
Licensing conditions of the following files were disputed when DNF was forked
|
||||
from Yum:
|
||||
from YUM:
|
||||
|
||||
yum/misc.py
|
||||
yum/parser.py
|
||||
|
||||
In the yum-devel-list-thread below those concernes were resolved by Yum
|
||||
In the yum-devel-list-thread below those concernes were resolved by YUM
|
||||
maintainers who confirmed these files were covered by GPLv2+:
|
||||
|
||||
http://lists.baseurl.org/pipermail/yum-devel/2012-July/009376.html
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
###############
|
||||
Dandified Yum
|
||||
Dandified YUM
|
||||
###############
|
||||
|
||||
.. image:: https://raw.githubusercontent.com/rpm-software-management/dnf/gh-pages/logos/DNF_logo.png
|
||||
|
||||
Dandified Yum (DNF) is the next upcoming major version of `Yum <http://yum.baseurl.org/>`_. It does package management using `RPM <http://rpm.org/>`_, `libsolv <https://github.com/openSUSE/libsolv>`_ and `hawkey <https://github.com/rpm-software-management/hawkey>`_ libraries. For metadata handling and package downloads it utilizes `librepo <https://github.com/tojaj/librepo>`_. To process and effectively handle the comps data it uses `libcomps <https://github.com/midnightercz/libcomps>`_.
|
||||
Dandified YUM (DNF) is the next upcoming major version of `YUM <http://yum.baseurl.org/>`_. It does package management using `RPM <http://rpm.org/>`_, `libsolv <https://github.com/openSUSE/libsolv>`_ and `hawkey <https://github.com/rpm-software-management/hawkey>`_ libraries. For metadata handling and package downloads it utilizes `librepo <https://github.com/tojaj/librepo>`_. To process and effectively handle the comps data it uses `libcomps <https://github.com/midnightercz/libcomps>`_.
|
||||
|
||||
============
|
||||
Installing
|
||||
|
|
@ -105,4 +105,4 @@ The DNF package distribution contains man pages, dnf(8) and dnf.conf(8). It is a
|
|||
|
||||
Please report discovered bugs to the `Red Hat bugzilla <https://bugzilla.redhat.com/>`_ following this `guide <https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting>`_. If you planned to propose the patch in the report, consider `Contribution`_ instead.
|
||||
|
||||
Freenode's irc channel ``#yum`` is meant for discussions related to both Yum and DNF. Questions should be asked there, issues discussed. Remember: ``#yum`` is not a support channel and prior research is expected from the questioner.
|
||||
Freenode's irc channel ``#yum`` is meant for discussions related to both YUM and DNF. Questions should be asked there, issues discussed. Remember: ``#yum`` is not a support channel and prior research is expected from the questioner.
|
||||
|
|
|
|||
|
|
@ -2000,7 +2000,7 @@ class CliKeyImport(dnf.callback.KeyImport):
|
|||
|
||||
|
||||
class CliTransactionDisplay(LoggingTransactionDisplay):
|
||||
"""A Yum specific callback class for RPM operations."""
|
||||
"""A YUM specific callback class for RPM operations."""
|
||||
|
||||
width = property(lambda self: dnf.cli.term._term_width())
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# __init__.py
|
||||
# The legacy Yum subpackage.
|
||||
# The legacy YUM subpackage.
|
||||
#
|
||||
# Copyright (C) 2013 Red Hat, Inc.
|
||||
#
|
||||
|
|
|
|||
|
|
@ -15,19 +15,19 @@
|
|||
License and may only be used or replicated with the express permission of
|
||||
Red Hat, Inc.
|
||||
|
||||
#########################################
|
||||
Changes in the DNF hook API compared to Yum
|
||||
#########################################
|
||||
#############################################
|
||||
Changes in the DNF hook API compared to YUM
|
||||
#############################################
|
||||
|
||||
|
||||
.. only :: html
|
||||
|
||||
|
||||
This table provides what alternative hooks are available in DNF compared to
|
||||
yum.
|
||||
YUM.
|
||||
|
||||
=========== ================= ==============================
|
||||
Hook Number Yum hook DNF hook
|
||||
Hook Number YUM hook DNF hook
|
||||
----------- ----------------- ------------------------------
|
||||
``1`` ``config`` ``init``
|
||||
``2`` ``postconfig`` ``init``
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
Red Hat, Inc.
|
||||
|
||||
####################################
|
||||
Changes in DNF CLI compared to Yum
|
||||
Changes in DNF CLI compared to YUM
|
||||
####################################
|
||||
|
||||
.. only :: html
|
||||
|
|
@ -36,7 +36,7 @@ in dnf.conf file. See :ref:`strict conf option <strict-label>`.
|
|||
|
||||
For upgrade command:
|
||||
|
||||
The semantics that were supposed to trigger in Yum with ``--skip-broken`` are now set for plain
|
||||
The semantics that were supposed to trigger in YUM with ``--skip-broken`` are now set for plain
|
||||
``dnf update`` as a default. There is no need to use ``--skip-broken`` with the ``dnf upgrade``
|
||||
command. To use only the latest versions of packages in transactions, there is the ``--best``
|
||||
command line switch.
|
||||
|
|
@ -46,7 +46,7 @@ Update and Upgrade Commands are the Same
|
|||
========================================
|
||||
|
||||
Invoking ``dnf update`` or ``dnf upgrade``, in all their forms, has the same
|
||||
effect in DNF, with the latter being preferred. In Yum ``yum upgrade`` was
|
||||
effect in DNF, with the latter being preferred. In YUM ``yum upgrade`` was
|
||||
exactly like ``yum --obsoletes update``.
|
||||
|
||||
================================================
|
||||
|
|
@ -55,21 +55,21 @@ exactly like ``yum --obsoletes update``.
|
|||
|
||||
The :ref:`clean_requirements_on_remove <clean_requirements_on_remove-label>`
|
||||
switch is on by default in DNF. It can thus be confusing to compare the "remove"
|
||||
operation results between DNF and Yum as by default DNF is often going to remove
|
||||
operation results between DNF and YUM as by default DNF is often going to remove
|
||||
more packages.
|
||||
|
||||
===========================
|
||||
No ``resolvedep`` command
|
||||
===========================
|
||||
|
||||
The Yum version of this command is maintained for legacy reasons only. The user
|
||||
The YUM version of this command is maintained for legacy reasons only. The user
|
||||
can just use ``dnf provides`` to find out what package provides a particular file.
|
||||
|
||||
===========================
|
||||
No ``deplist`` command
|
||||
===========================
|
||||
|
||||
An alternative to the Yum ``deplist`` command to find out dependencies of a package
|
||||
An alternative to the YUM ``deplist`` command to find out dependencies of a package
|
||||
is ``dnf repoquery --deplist`` using :ref:`repoquery command
|
||||
<repoquery_command-label>`.
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ is ``dnf repoquery --deplist`` using :ref:`repoquery command
|
|||
Excludes and repo excludes apply to all operations
|
||||
====================================================
|
||||
|
||||
Yum only respects excludes during installs and upgrades. DNF extends this to all
|
||||
YUM only respects excludes during installs and upgrades. DNF extends this to all
|
||||
operations, among others erasing and listing. If you e.g. want to see a list of
|
||||
all installed ``python-f*`` packages but not any of the Flask packages, the
|
||||
following will work::
|
||||
|
|
@ -88,7 +88,7 @@ following will work::
|
|||
dnf -x '*flask*' list installed 'python-f*'
|
||||
|
||||
==========================================================
|
||||
Yum's conf directive ``includepkgs`` is just ``include``
|
||||
YUM's conf directive ``includepkgs`` is just ``include``
|
||||
==========================================================
|
||||
|
||||
``include`` directive name of [main] and Repo configuration is a more logical and better named counterpart of ``exclude`` in DNF.
|
||||
|
|
@ -97,7 +97,7 @@ following will work::
|
|||
``dnf remove kernel`` deletes all packages called ``kernel``
|
||||
=============================================================
|
||||
|
||||
In Yum, the running kernel is spared. There is no reason to keep this in DNF,
|
||||
In YUM, the running kernel is spared. There is no reason to keep this in DNF,
|
||||
the user can always specify concrete versions on the command line, e.g.::
|
||||
|
||||
dnf remove kernel-3.9.4
|
||||
|
|
@ -115,7 +115,7 @@ such as::
|
|||
|
||||
dnf provides /b*/<file>
|
||||
|
||||
will fail still (as they do in Yum now). To find what provides a particular
|
||||
will fail still (as they do in YUM now). To find what provides a particular
|
||||
binary, use the actual path for binaries on Fedora::
|
||||
|
||||
dnf provides /usr/bin/<file>
|
||||
|
|
@ -133,7 +133,7 @@ Also see related Fedora bugzillas `982947
|
|||
The important system repos should never be down and we see the third-party repos
|
||||
down often enough to warrant this change. Note that without this setting and
|
||||
without an explicit ``skip_if_unavailable=True`` in the relevant repo .ini file
|
||||
Yum immediately stops on a repo error, confusing and bothering the user.
|
||||
YUM immediately stops on a repo error, confusing and bothering the user.
|
||||
|
||||
See the related `Fedora bug 984483 <https://bugzilla.redhat.com/show_bug.cgi?id=984483>`_.
|
||||
|
||||
|
|
@ -221,25 +221,25 @@ DNF provides swap command but only ``dnf swap A B`` syntax is supported
|
|||
Dependency processing details are not shown in the CLI
|
||||
========================================================
|
||||
|
||||
During its depsolving phase, Yum outputs lines similar to::
|
||||
During its depsolving phase, YUM outputs lines similar to::
|
||||
|
||||
---> Package rubygem-rhc.noarch 0:1.16.9-1.fc19 will be an update
|
||||
--> Processing Dependency: rubygem-net-ssh-multi >= 1.2.0 for package: rubygem-rhc-1.16.9-1.fc19.noarch
|
||||
|
||||
DNF does not output information like this. The technical reason is that depsolver below DNF always considers all dependencies for update candidates and the output would be very long. Secondly, even in Yum this output gets confusing very quickly especially for large transactions and so does more harm than good.
|
||||
DNF does not output information like this. The technical reason is that depsolver below DNF always considers all dependencies for update candidates and the output would be very long. Secondly, even in YUM this output gets confusing very quickly especially for large transactions and so does more harm than good.
|
||||
|
||||
See the the related `Fedora bug 1044999
|
||||
<https://bugzilla.redhat.com/show_bug.cgi?id=1044999>`_.
|
||||
|
||||
===================================================================
|
||||
``dnf provides`` complies with the Yum documentation of the command
|
||||
``dnf provides`` complies with the YUM documentation of the command
|
||||
===================================================================
|
||||
|
||||
When one executes::
|
||||
|
||||
yum provides sandbox
|
||||
|
||||
Yum applies extra heuristics to determine what the user meant by ``sandbox``, for instance it sequentially prepends entries from the ``PATH`` environment variable to it to see if it matches a file provided by some package. This is an undocumented behavior that DNF does not emulate. Just typically use::
|
||||
YUM applies extra heuristics to determine what the user meant by ``sandbox``, for instance it sequentially prepends entries from the ``PATH`` environment variable to it to see if it matches a file provided by some package. This is an undocumented behavior that DNF does not emulate. Just typically use::
|
||||
|
||||
dnf provides /usr/bin/sandbox
|
||||
|
||||
|
|
@ -253,28 +253,28 @@ to obtain similar results.
|
|||
``--enableplugin`` not recognized
|
||||
=================================
|
||||
|
||||
This switch has been dropped. It is not documented for Yum and of questionable use (all plugins are enabled by default).
|
||||
This switch has been dropped. It is not documented for YUM and of questionable use (all plugins are enabled by default).
|
||||
|
||||
==================
|
||||
Bandwidth limiting
|
||||
==================
|
||||
|
||||
DNF supports the ``throttle`` and ``bandwidth`` options familiar from Yum.
|
||||
Contrary to Yum, when multiple downloads run simultaneously the total
|
||||
downloading speed is throttled. This was not possible in Yum since
|
||||
DNF supports the ``throttle`` and ``bandwidth`` options familiar from YUM.
|
||||
Contrary to YUM, when multiple downloads run simultaneously the total
|
||||
downloading speed is throttled. This was not possible in YUM since
|
||||
downloaders ran in different processes.
|
||||
|
||||
===================================
|
||||
``installonlypkgs`` config option
|
||||
===================================
|
||||
|
||||
Compared to Yum, DNF appends list values from the ``installonlypkgs`` config option to DNF defaults, where YUM overwrites the defaults by option values.
|
||||
Compared to YUM, DNF appends list values from the ``installonlypkgs`` config option to DNF defaults, where YUM overwrites the defaults by option values.
|
||||
|
||||
==============================
|
||||
The usage of Delta RPM files
|
||||
==============================
|
||||
|
||||
The boolean ``deltarpm`` option controls whether delta RPM files are used. Compared to Yum, DNF does not support ``deltarpm_percentage`` and instead chooses some optimal value of DRPM/RPM ratio to decide whether using deltarpm makes sense in the given case.
|
||||
The boolean ``deltarpm`` option controls whether delta RPM files are used. Compared to YUM, DNF does not support ``deltarpm_percentage`` and instead chooses some optimal value of DRPM/RPM ratio to decide whether using deltarpm makes sense in the given case.
|
||||
|
||||
================================================
|
||||
Handling .srpm files and non-existent packages
|
||||
|
|
@ -287,13 +287,13 @@ DNF will terminate early with an error if a command is executed requesting an in
|
|||
|
||||
The same applies for package specifications that do not match any available package.
|
||||
|
||||
Yum will only issue a warning in this case and continue installing the "tour" package. The rationale behind the result in DNF is that a program should terminate with an error if it can not fulfill the CLI command in its entirety.
|
||||
YUM will only issue a warning in this case and continue installing the "tour" package. The rationale behind the result in DNF is that a program should terminate with an error if it can not fulfill the CLI command in its entirety.
|
||||
|
||||
=============================================================
|
||||
Promoting package to install to a package that obsoletes it
|
||||
=============================================================
|
||||
|
||||
DNF will not magically replace a request for installing package ``X`` to installing package ``Y`` if ``Y`` obsoletes ``X``. Yum does this if its ``obsoletes`` config option is enabled but the behavior is not properly documented and can be harmful.
|
||||
DNF will not magically replace a request for installing package ``X`` to installing package ``Y`` if ``Y`` obsoletes ``X``. YUM does this if its ``obsoletes`` config option is enabled but the behavior is not properly documented and can be harmful.
|
||||
|
||||
See the the related `Fedora bug 1096506
|
||||
<https://bugzilla.redhat.com/show_bug.cgi?id=1096506>`_ and `guidelines for renaming and obsoleting packages in Fedora <http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages>`_.
|
||||
|
|
@ -304,18 +304,18 @@ Behavior of ``--installroot`` option
|
|||
|
||||
DNF offers more predictable behavior of installroot. DNF handles the path differently
|
||||
from the ``--config`` command-line option, where this path is always related to the host
|
||||
system (Yum combines this path with installroot). Reposdir is also handled slightly
|
||||
system (YUM combines this path with installroot). Reposdir is also handled slightly
|
||||
differently, if one path of the reposdirs exists inside of installroot, then
|
||||
repos are strictly taken from installroot (Yum tests each path from reposdir
|
||||
repos are strictly taken from installroot (YUM tests each path from reposdir
|
||||
separately and use installroot path if existed). See the detailed description for
|
||||
\-\ :ref:`-installroot <installroot-label>` option.
|
||||
|
||||
###############################################
|
||||
Changes in DNF plugins compared to Yum plugins
|
||||
Changes in DNF plugins compared to YUM plugins
|
||||
###############################################
|
||||
|
||||
====================================== ================================================================ ===================================
|
||||
Original Yum tool DNF command/option Package
|
||||
Original YUM tool DNF command/option Package
|
||||
-------------------------------------- ---------------------------------------------------------------- -----------------------------------
|
||||
``yum check`` :ref:`dnf repoquery <repoquery_command-label>` ``--unsatisfied`` ``dnf``
|
||||
``yum-langpacks`` ``dnf-langpacks``
|
||||
|
|
@ -352,13 +352,13 @@ Plugins that have not been ported yet:
|
|||
Feel free to file an RFE_ for missing functionality if you need it.
|
||||
|
||||
#################################################
|
||||
Changes in DNF plugins compared to Yum utilities
|
||||
Changes in DNF plugins compared to YUM utilities
|
||||
#################################################
|
||||
|
||||
All ported Yum tools are now implemented as DNF plugins.
|
||||
All ported YUM tools are now implemented as DNF plugins.
|
||||
|
||||
========================= ================================================ =================================
|
||||
Original Yum tool New DNF command Package
|
||||
Original YUM tool New DNF command Package
|
||||
------------------------- ------------------------------------------------ ---------------------------------
|
||||
``debuginfo-install`` `dnf debuginfo-install`_ ``dnf-plugins-core``
|
||||
``find-repos-of-install`` `dnf list installed`_ ``dnf``
|
||||
|
|
@ -399,7 +399,7 @@ Utilities that have not been ported yet:
|
|||
``verifytree``,
|
||||
``yum-groups-manager``
|
||||
|
||||
Take a look at the FAQ_ about Yum to DNF migration. Feel free to file an RFE_ for missing functionality if you need it.
|
||||
Take a look at the FAQ_ about YUM to DNF migration. Feel free to file an RFE_ for missing functionality if you need it.
|
||||
|
||||
.. _dnf debuginfo-install: http://dnf-plugins-core.readthedocs.org/en/latest/debuginfo-install.html
|
||||
.. _dnf list installed: http://dnf.readthedocs.org/en/latest/command_ref.html
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ Description
|
|||
|
||||
.. _command_provides-label:
|
||||
|
||||
`DNF`_ is the next upcoming major version of `Yum`_, a package manager for RPM-based Linux
|
||||
distributions. It roughly maintains CLI compatibility with Yum and defines a strict API for
|
||||
`DNF`_ is the next upcoming major version of `YUM`_, a package manager for RPM-based Linux
|
||||
distributions. 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
|
||||
|
|
@ -1450,6 +1450,6 @@ See Also
|
|||
* :manpage:`dnf.plugin.*(8)`, assorted DNF plugins that might be installed on the system.
|
||||
* `DNF`_ project homepage (https://github.com/rpm-software-management/dnf/)
|
||||
* How to report a bug (https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting)
|
||||
* `Yum`_ project homepage (http://yum.baseurl.org/)
|
||||
* `YUM`_ project homepage (http://yum.baseurl.org/)
|
||||
|
||||
.. _dnf config-manager: https://dnf-plugins-core.readthedocs.org/en/latest/config_manager.html
|
||||
|
|
|
|||
|
|
@ -240,9 +240,9 @@ man_pages = [
|
|||
AUTHORS, 5),
|
||||
('conf_ref', 'yum.conf', u'redirecting to DNF Configuration Reference',
|
||||
AUTHORS, 5),
|
||||
('cli_vs_yum', 'yum2dnf', u'Changes in DNF compared to Yum',
|
||||
('cli_vs_yum', 'yum2dnf', u'Changes in DNF compared to YUM',
|
||||
AUTHORS, 8),
|
||||
('command_ref', 'yum', u'/usr/bin/yum to /usr/bin/dnf redirecting executable',
|
||||
('command_ref', 'yum', u'redirecting to DNF Command Reference',
|
||||
AUTHORS, 8),
|
||||
]
|
||||
|
||||
|
|
@ -274,6 +274,6 @@ rst_prolog = """
|
|||
.. default-domain:: py
|
||||
.. _DNF: https://github.com/rpm-software-management/dnf/
|
||||
.. _hawkey: http://rpm-software-management.github.io/hawkey/
|
||||
.. _Yum: http://yum.baseurl.org/
|
||||
.. _YUM: http://yum.baseurl.org/
|
||||
.. _bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf
|
||||
"""
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
Red Hat, Inc.
|
||||
|
||||
#############################################
|
||||
DNF, the next-generation replacement for Yum
|
||||
DNF, the next-generation replacement for YUM
|
||||
#############################################
|
||||
|
||||
Contents:
|
||||
|
|
|
|||
|
|
@ -960,7 +960,7 @@ Bugs fixed in 0.6.1:
|
|||
|
||||
0.6.0 marks a new minor version of DNF and the first release to support advisories listing with the :ref:`udpateinfo command <updateinfo_command-label>`.
|
||||
|
||||
Support for the :ref:`include configuration directive <include-label>` has been added. Its functionality reflects Yum's ``includepkgs`` but it has been renamed to make it consistent with the ``exclude`` setting.
|
||||
Support for the :ref:`include configuration directive <include-label>` has been added. Its functionality reflects YUM's ``includepkgs`` but it has been renamed to make it consistent with the ``exclude`` setting.
|
||||
|
||||
Group operations now produce a list of proposed marking changes to group objects and the user is given a chance to accept or reject them just like with an ordinary package transaction.
|
||||
|
||||
|
|
@ -1007,7 +1007,7 @@ Bugs fixed in 0.5.5:
|
|||
|
||||
Several encodings bugs were fixed in this release, along with some packaging issues and updates to :doc:`conf_ref`.
|
||||
|
||||
Repository :ref:`priority <repo_priority-label>` configuration setting has been added, providing similar functionality to Yum Utils' Priorities plugin.
|
||||
Repository :ref:`priority <repo_priority-label>` configuration setting has been added, providing similar functionality to YUM Utils' Priorities plugin.
|
||||
|
||||
Bugs fixed in 0.5.4:
|
||||
|
||||
|
|
@ -1027,7 +1027,7 @@ Bugs fixed in 0.5.4:
|
|||
0.5.3 Release Notes
|
||||
===================
|
||||
|
||||
A set of bugfixes related to i18n and Unicode handling. There is a ``-4/-6`` switch and a corresponding :ref:`ip_resolve <ip-resolve-label>` configuration option (both known from Yum) to force DNS resolving of hosts to IPv4 or IPv6 addresses.
|
||||
A set of bugfixes related to i18n and Unicode handling. There is a ``-4/-6`` switch and a corresponding :ref:`ip_resolve <ip-resolve-label>` configuration option (both known from YUM) to force DNS resolving of hosts to IPv4 or IPv6 addresses.
|
||||
|
||||
0.5.3 comes with several extensions and clarifications in the API: notably :class:`~.dnf.transaction.Transaction` is introspectible now, :class:`Query.filter <dnf.query.Query.filter>` is more useful with new types of arguments and we've hopefully shed more light on how a client is expected to setup the configuration :attr:`~dnf.conf.Conf.substitutions`.
|
||||
|
||||
|
|
@ -1110,7 +1110,7 @@ Bugs fixed in 0.5.1:
|
|||
0.5.0 Release Notes
|
||||
===================
|
||||
|
||||
The biggest improvement in 0.5.0 is complete support for groups `and environments <https://bugzilla.redhat.com/show_bug.cgi?id=1063666>`_, including internal database of installed groups independent of the actual packages (concept known as groups-as-objects from Yum). Upgrading groups is supported now with ``group upgrade`` too.
|
||||
The biggest improvement in 0.5.0 is complete support for groups `and environments <https://bugzilla.redhat.com/show_bug.cgi?id=1063666>`_, including internal database of installed groups independent of the actual packages (concept known as groups-as-objects from YUM). Upgrading groups is supported now with ``group upgrade`` too.
|
||||
|
||||
To force refreshing of metadata before an operation (even if the data is not expired yet), `the refresh option has been added <https://bugzilla.redhat.com/show_bug.cgi?id=1064226>`_.
|
||||
|
||||
|
|
@ -1187,7 +1187,7 @@ Bugs fixed in 0.4.19:
|
|||
|
||||
Support for ``dnf distro-sync <spec>`` finally arrives in this version.
|
||||
|
||||
DNF has moved to handling groups as objects, tagged installed/uninstalled independently from the actual installed packages. This has been in Yum as the ``group_command=objects`` setting and the default in recent Fedora releases. There are API extensions related to this change as well as two new CLI commands: ``group mark install`` and ``group mark remove``.
|
||||
DNF has moved to handling groups as objects, tagged installed/uninstalled independently from the actual installed packages. This has been in YUM as the ``group_command=objects`` setting and the default in recent Fedora releases. There are API extensions related to this change as well as two new CLI commands: ``group mark install`` and ``group mark remove``.
|
||||
|
||||
API items deprecated in 0.4.8 and 0.4.9 have been dropped in 0.4.18, in accordance with our :ref:`deprecating-label`.
|
||||
|
||||
|
|
@ -1353,7 +1353,7 @@ Bugs fixed in 0.4.11:
|
|||
|
||||
``dnf install`` now accepts group specifications via the ``@`` character.
|
||||
|
||||
Support for the ``--setopt`` option has been readded from Yum.
|
||||
Support for the ``--setopt`` option has been readded from YUM.
|
||||
|
||||
API additions in 0.4.10:
|
||||
|
||||
|
|
@ -1386,7 +1386,7 @@ Bugs fixed in 0.4.10:
|
|||
0.4.9 Release Notes
|
||||
===================
|
||||
|
||||
Several Yum features are revived in this release. ``dnf history rollback`` now works again. The ``history userinstalled`` has been added, it displays a list of ackages that the user manually selected for installation on an installed system and does not include those packages that got installed as dependencies.
|
||||
Several YUM features are revived in this release. ``dnf history rollback`` now works again. The ``history userinstalled`` has been added, it displays a list of ackages that the user manually selected for installation on an installed system and does not include those packages that got installed as dependencies.
|
||||
|
||||
We're happy to announce that the API in 0.4.9 has been extended to finally support plugins. There is a limited set of plugin hooks now, we will carefully add new ones in the following releases. New marking operations have ben added to the API and also some configuration options.
|
||||
|
||||
|
|
@ -1464,7 +1464,7 @@ We start to publish the :doc:`api` with this release. It is largely
|
|||
incomprehensive at the moment, yet outlines the shape of the documentation and
|
||||
the process the project is going to use to maintain it.
|
||||
|
||||
There are two Yum configuration options that were dropped: :ref:`group_package_types <group_package_types_dropped>` and :ref:`upgrade_requirements_on_install <upgrade_requirements_on_install_dropped>`.
|
||||
There are two YUM configuration options that were dropped: :ref:`group_package_types <group_package_types_dropped>` and :ref:`upgrade_requirements_on_install <upgrade_requirements_on_install_dropped>`.
|
||||
|
||||
Bugs fixed in 0.4.7:
|
||||
|
||||
|
|
@ -1742,7 +1742,7 @@ The following bugfixes are included in 0.3.5:
|
|||
0.3.4 Release Notes
|
||||
===================
|
||||
|
||||
0.3.4 is the first DNF version since the fork from Yum that is able to
|
||||
0.3.4 is the first DNF version since the fork from YUM that is able to
|
||||
manipulate the comps data. In practice, ``dnf group install <group name>`` works
|
||||
again. No other group commands are supported yet.
|
||||
|
||||
|
|
@ -1750,7 +1750,7 @@ Support for ``librepo-0.0.4`` and related cleanups and extensions this new
|
|||
version allows are included (see the buglist below)
|
||||
|
||||
This version has also improved reporting of obsoleted packages in the CLI (the
|
||||
Yum-style "replacing <package-nevra>" appears in the textual transaction
|
||||
YUM-style "replacing <package-nevra>" appears in the textual transaction
|
||||
overview).
|
||||
|
||||
The following bugfixes are included in 0.3.4:
|
||||
|
|
@ -1765,7 +1765,7 @@ The following bugfixes are included in 0.3.4:
|
|||
|
||||
The improvements in 0.3.3 are only API changes to the logging. There is a new
|
||||
module ``dnf.logging`` that defines simplified logging structure compared to
|
||||
Yum, with fewer logging levels and `simpler usage for the developers
|
||||
YUM, with fewer logging levels and `simpler usage for the developers
|
||||
<https://github.com/rpm-software-management/dnf/wiki/Hacking#logging>`_. The RPM transaction logs are
|
||||
no longer in ``/var/log/dnf.transaction.log`` but in ``/var/log/dnf.rpm.log`` by
|
||||
default.
|
||||
|
|
@ -1785,7 +1785,7 @@ The major improvement in this version is in speeding up syncing of repositories
|
|||
using metalink by looking at the repomd.xml checksums. This effectively lets DNF
|
||||
cheaply refresh expired repositories in cases where the original has not
|
||||
changed\: for instance the main Fedora repository is refreshed with one 30 kB
|
||||
HTTP download. This functionality is present in the current Yum but hasn't
|
||||
HTTP download. This functionality is present in the current YUM but hasn't
|
||||
worked in DNF since 3.0.0.
|
||||
|
||||
Otherwise this is mainly a release fixing bugs and tracebacks. The following
|
||||
|
|
|
|||
|
|
@ -28,14 +28,14 @@ General Questions
|
|||
What does DNF stand for?
|
||||
========================
|
||||
|
||||
Dandified `Yum <http://yum.baseurl.org/>`_.
|
||||
Dandified `YUM <http://yum.baseurl.org/>`_.
|
||||
|
||||
Can I have DNF and Yum installed side by side?
|
||||
Can I have DNF and YUM installed side by side?
|
||||
==============================================
|
||||
|
||||
Yes, you can. And this setup is tested by many.
|
||||
|
||||
There is one restriction: DNF and Yum keep additional data about each installed package and every performed transaction. This data is currently not shared between the two managers so if the admin installs half of the packages with DNF and the other half with Yum then each program can not benefit from the information held by the other one. The practical bottom line is that commands like ``autoremove`` can not take a completely informed decision and thus have to "play it safe" and remove only a subset of dependencies they would be able to otherwise. Similar situation exists with groups.
|
||||
There is one restriction: DNF and YUM keep additional data about each installed package and every performed transaction. This data is currently not shared between the two managers so if the admin installs half of the packages with DNF and the other half with YUM then each program can not benefit from the information held by the other one. The practical bottom line is that commands like ``autoremove`` can not take a completely informed decision and thus have to "play it safe" and remove only a subset of dependencies they would be able to otherwise. Similar situation exists with groups.
|
||||
|
||||
To transfer transaction additional data from yum to DNF, run::
|
||||
|
||||
|
|
@ -43,10 +43,10 @@ To transfer transaction additional data from yum to DNF, run::
|
|||
|
||||
.. _dnf_yum_package-label:
|
||||
|
||||
Is there a compatibility layer for Yum?
|
||||
Is there a compatibility layer for YUM?
|
||||
=======================================
|
||||
|
||||
For the CLI, yes. Just install ``dnf-yum`` which supplies our own ``/usr/bin/yum``. Note two things: all the :doc:`differences <cli_vs_yum>` between the two package managers still apply and this does not provide "yum" in terms of package dependencies (it conflicts with the Yum package though).
|
||||
For the CLI, yes. Just install ``dnf-yum`` which supplies our own ``/usr/bin/yum``. Note two things: all the :doc:`differences <cli_vs_yum>` between the two package managers still apply and this does not provide "yum" in terms of package dependencies (it conflicts with the YUM package though).
|
||||
|
||||
|
||||
What to do with packages that DNF refuses to remove because their ``%pre`` or ``%preun`` scripts are failing?
|
||||
|
|
@ -90,7 +90,7 @@ Why do I get different results with ``dnf upgrade`` vs ``yum update``?
|
|||
|
||||
We get this reported as a bug quite often, but it usually is not. One reason to see this is that DNF does not list update candidates as it explores them. More frequently however the reporter means actual difference in the proposed transaction. This is most often because the metadata the two packagers are working with were taken at a different time (DNF has a notoriously looser schedule on metadata updates to save time and bandwidth), and sometimes also because the depsolvers inside are designed to take a different course of action when encountering some specific update scenario.
|
||||
|
||||
The bottom line is: unless a real update problem occurs (i.e. DNF refuses to update a package that Yum updates) with the same set of metadata, this is not an issue.
|
||||
The bottom line is: unless a real update problem occurs (i.e. DNF refuses to update a package that YUM updates) with the same set of metadata, this is not an issue.
|
||||
|
||||
Is it possible to force DNF to get the latest metadata on ``dnf upgrade``?
|
||||
==========================================================================
|
||||
|
|
|
|||
Loading…
Reference in New Issue