|
Packit Service |
21c75c |
..
|
|
Packit Service |
21c75c |
Copyright (C) 2014-2016 Red Hat, Inc.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
This copyrighted material is made available to anyone wishing to use,
|
|
Packit Service |
21c75c |
modify, copy, or redistribute it subject to the terms and conditions of
|
|
Packit Service |
21c75c |
the GNU General Public License v.2, or (at your option) any later version.
|
|
Packit Service |
21c75c |
This program is distributed in the hope that it will be useful, but WITHOUT
|
|
Packit Service |
21c75c |
ANY WARRANTY expressed or implied, including the implied warranties of
|
|
Packit Service |
21c75c |
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
|
|
Packit Service |
21c75c |
Public License for more details. You should have received a copy of the
|
|
Packit Service |
21c75c |
GNU General Public License along with this program; if not, write to the
|
|
Packit Service |
21c75c |
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
|
|
Packit Service |
21c75c |
02110-1301, USA. Any Red Hat trademarks that are incorporated in the
|
|
Packit Service |
21c75c |
source code or documentation are not subject to the GNU General Public
|
|
Packit Service |
21c75c |
License and may only be used or replicated with the express permission of
|
|
Packit Service |
21c75c |
Red Hat, Inc.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
################
|
|
Packit Service |
21c75c |
DNF User's FAQ
|
|
Packit Service |
21c75c |
################
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
.. contents::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
=================
|
|
Packit Service |
21c75c |
General Questions
|
|
Packit Service |
21c75c |
=================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
What does DNF stand for?
|
|
Packit Service |
21c75c |
========================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Dandified `YUM <http://yum.baseurl.org/>`_.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Can I have DNF and YUM installed side by side?
|
|
Packit Service |
21c75c |
==============================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Yes, you can. And this setup is tested by many.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
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.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
To transfer transaction additional data from yum to DNF, run::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
.. _dnf_yum_package-label:
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Is there a compatibility layer for YUM?
|
|
Packit Service |
21c75c |
=======================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
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).
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
What to do with packages that DNF refuses to remove because their ``%pre`` or ``%preun`` scripts are failing?
|
|
Packit Service |
21c75c |
=============================================================================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
If this happens, it is a packaging error and consider reporting the failure to
|
|
Packit Service |
21c75c |
the package's maintainer.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
You can usually remove such package with ``rpm``::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
rpm -e <package-version> --noscripts
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Why are ``dnf check-update`` packages not marked for upgrade in the following ``dnf upgrade``
|
|
Packit Service |
21c75c |
=============================================================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Sometimes one can see that a newer version of a package is available in the repos::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
$ dnf check-update
|
|
Packit Service |
21c75c |
libocsync0.x86_64 0.91.4-2.1 devel_repo
|
|
Packit Service |
21c75c |
owncloud-client.x86_64 1.5.0-18.1 devel_repo
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Yet the immediately following ``dnf upgrade`` does not offer them for upgrade::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
$ dnf upgrade
|
|
Packit Service |
21c75c |
Resolving dependencies
|
|
Packit Service |
21c75c |
--> Starting dependency resolution
|
|
Packit Service |
21c75c |
--> Finished dependency resolution
|
|
Packit Service |
21c75c |
Dependencies resolved.
|
|
Packit Service |
21c75c |
Nothing to do.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
It might seem odd but in fact this can happen quite easily: what the first command does is only check whether there are some available packages with the same name as an installed package but with a higher version. Those are considered upgrade candidates by ``check-update``, but no actual dependency resolving takes place there. That only happens during ``dnf upgrade`` and if the resolving procedure then discovers that some of the packages do not have their dependencies ready yet, then they are not offered in the upgrade. To see the precise reason why it was not possible to do the upgrade in this case, use::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
$ dnf upgrade --best
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
In DNF version 1.1 and above, you can see the skipped packages in the special transaction summary section. In order to pull these packages into transaction one has to remove conflicting packages, to do that execute::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
$ dnf upgrade --best --allowerasing
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Why do I get different results with ``dnf upgrade`` vs ``yum update``?
|
|
Packit Service |
21c75c |
======================================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
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.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
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.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Is it possible to force DNF to get the latest metadata on ``dnf upgrade``?
|
|
Packit Service |
21c75c |
==========================================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Yes, clear the cache first::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
$ dnf clean metadata
|
|
Packit Service |
21c75c |
$ dnf upgrade
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
or by one command line simply put::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
$ dnf upgrade --refresh
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
An alternative is to shorten the default expiry time of repos, for that edit ``/etc/dnf/dnf.conf`` and set::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
metadata_expire=0
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Of course, some repos might use a custom ``metadata_expire`` value, you'll currently have to change these manually too.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
If you're the kind of the user who always wants the freshest metadata possible, you'll probably want to :ref:`disable the automatic MD updates <disabling_makecache_service-label>`.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
.. _disabling_makecache_service-label:
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
How do I disable automatic metadata synchronization service?
|
|
Packit Service |
21c75c |
============================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Several ways to do that. The DNF way is to add the following to ``/etc/dnf/dnf.conf``::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
metadata_timer_sync=0
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Shouldn't DNF exit soon from certain commands if it is not run under root?
|
|
Packit Service |
21c75c |
==========================================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
No, there can be systems and scenarios that allow other users than root to successfully perform ``dnf install`` and similar and it would be impractical to stop these from functioning by the UID check. Alternatively, the practice of checking filesystem permissions instead of the effective UID could lead to false positives since there is plenty of time between DNF startup and the possible transaction start when permissions can be changed by a different process.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
If the time loss incurred by repeated runs of DNF is unacceptable for you, consider using the `noroot plugin <https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/noroot.py>`_.
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
===================
|
|
Packit Service |
21c75c |
Using DNF in Fedora
|
|
Packit Service |
21c75c |
===================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
For my stable Fedora release, can I install the rawhide packages for testing purposes?
|
|
Packit Service |
21c75c |
======================================================================================
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Yes, in two steps: first install the necessary ``.repo`` files::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
dnf install fedora-repos-rawhide
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Then, when you want to include the packages from the rawhide repo, execute a DNF command with Rawhide enabled::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
dnf --enablerepo=rawhide upgrade rpm
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
.. note::
|
|
Packit Service |
21c75c |
|
|
Packit Service |
21c75c |
Installing rawhide packages onto a stable Fedora release system is generally discouraged as it leads to less tested combinations of installed packages. Please consider this step carefully.
|