Do you wonder why you don’t have yum package installed on the Fedora 22 clean installation and why you get warnings when calling /usr/bin/yum executable or any yum-util plugin about deprecation of Yum? You see right, Yum is gone. Literally. And DNF is the new default Fedora package manager.
DNF is fork of Yum with the state-of-art SAT-based dependency solver and was supposed to replace Yum in Fedora 22. Now with the release of DNF version 1.0 it is the time to fulfill this destiny. This radical change was inevitable. Yum would not survive the “Python 3 as default” Fedora initiative meanwhile DNF is able to run on Python 2 and Python 3. Command line interface was preserved when it made logical sense of command semantic. Fortunately DNF Python API is completely different from Yum. All known incompatibilities between these two projects are documented. In Fedora 22 Core is DNF only and Yum is officially considered dead project. If anyone wants to download Yum she or he can. The package is still called the same and Python API remains for the time being. Just the yum executable file was renamed to yum-deprecated, and yum calls from command line are redirected to DNF. This way you can maintain both Yum and DNF on the system at the same time.
The reason of initiating DNF project was because of the biggest three pitfalls of Yum: undocumented API, broken dependency solving algorithm and inability to refactor internal functions. The last mentioned issue is connected with the lack of documentation. Yum plugins are using any method from Yum code base thus any change there would cause the sudden crash of the Yum utility. The DNF aim was to avoid mistakes made in Yum. From the start all exposed API functions were properly documented. The tests were included with almost every new commit. No quick and dirty hacks are allowed. The project is directed by agile development – the features that have the greatest impact on users are operatively implemented with higher priority.
Nowadays DNF team is working on porting the rest of popular plugins from Yum to DNF and improving the user experience. To make the switch for you a little easier we have implemented DNF migration plugin for importing installed packages, groups and transaction metadata from Yum to the new Fedora package manager. Happy transition and enjoy the DNF ride!
Jan Silhan, by DNF team
Is there a command to initialise DNF in a chroot directory? That is install enough of DNF to chroot and run DNF from there?
That used to be a pain with yum…
You’d better try that on your own and report a bug (with your use case) then.
Seems easy now…
sudo dnf -y --installroot=/var/lib/libvirt/filesystems/f22test --releasever=22 --nogpg updateYour solution to an undocumented API (and the concomitant technical debt) is to create another API and more technical debt? I’ll never understand RH.
It really hard to maintain a project where you can’t change anything.
Neither can I. Not that my meaning matters, BTW.
But: undocumented API, broken dependency solving algorithm and inability to refactor internal functions. As a normal Fedora user, I never had any of the mentioned problems. Well, to be honest, I did have the dependency solving problem once. But that was due to using incompatible repositories. i.e. Using original Fedora repo’s and rpmforge (in that case). I solved this by creating a .spec file and repackage the software in question.
I don’t say that these problems don’t exist, just that most people will never notice them.
Hi Jan, will there be a replacement for yum extender? I know that Tim Lauridsen has done some work towards this – see Tim’s bog http://fedorarules.blogspot.ie/
Yes, it will be. It’s not in competence of dnf team but Tim Lauridsen. The project repo is active.
If it is a fork, why not continue to call it yum? DNF is not a particularly appealing name
“Just use dnf.” … Also, the original developer of yum was meant to have been a great guy killed tragically. Let his memory live on!
I agree. Yum is a better name and people already know it. It would be better marketing to stick to a name that people associate with Red Hat and Fedora. Dnf is an acronym that is meaningless to most people, while yum is actually a word that has a meaning in addition to being an acronym.
Changing the name of a critical command also makes it harder for people to learn to use the distribution.
That’s why we made yum-dnf compat package having yum -> dnf redirection
Sad News.
Does DNF works with drpm? What about GUI, like Yumex?
Of course it works with drpm and it’s enabled by default. Yumex will use DNF as backend.
best statement about documentation… ever.
Is it planed to introduce the newer verion of dnf to RHEL via epel.? At the moment there is only the version 0.6.4 without any possibility to migrate the “old” datas of yum.
The introduction would be really great.
DNF 0.6.4 is quite recent. DNF-PLUGINS-CORE will land into EPEL7 soon. Migrate plugin belongs to community plugins (DNF-PLUGINS-EXTRAS) and AFAIK they are not in EPEL7. You can write request to it’s maintainer.
DNF nice too, but I just read this blog, unfortunately I have not been able to practice, whether there is the theory that is much easier to me about this DNF
Based on your comments above about yum being dead and anyone could download it if they wanted, I though it would be ok on fedora 22 to delete it. Imagine my surprise when dnf erase yum told me all of these other things are going to be removed because yum is a dependency:
» sudo dnf erase yum
[sudo] password for patrick:
Dependencies resolved.
================================================================================
Package Arch Version Repository
Size
================================================================================
Removing:
bodhi-client noarch 0.9.12.2-1.fc22 @System 26 k
createrepo noarch 0.10.3-3.fc21 @System 301 k
eclipse-fedorapackager noarch 0.5.0-3.fc22 @System 2.9 M
fedora-easy-karma noarch 0-0.23.20140905git5fb5b77a.fc22
@System 77 k
fedora-packager noarch 0.5.10.5-1.fc22 @System 80 k
fedpkg noarch 1.20-1.fc22 @System 72 k
fedup noarch 0.9.2-1.fc22 @System 258 k
livecd-tools x86_64 1:22.1-1.fc22 @System 144 k
lorax x86_64 22.11-1.fc22 @System 461 k
lpf noarch 0.1-8.36e5aa0.fc22 @System 185 k
lpf-skype i686 4.3.0.37-2.fc21 @System 6.6 k
mock noarch 1.2.8-1.fc22 @System 946 k
mock-scm noarch 1.2.8-1.fc22 @System 6.9 k
pyrpkg noarch 1.33-1.fc22 @System 363 k
python-dnf-plugins-extras-migrate noarch 0.0.7-1.fc22 @System 25 k
python-imgcreate x86_64 1:22.1-1.fc22 @System 282 k
yum noarch 3.4.3-505.fc22 @System 5.6 M
yum-langpacks noarch 0.4.5-1.fc22 @System 66 k
yum-plugin-auto-update-debug-info noarch 1.1.31-505.fc22 @System 25 k
yum-plugin-remove-with-leaves noarch 1.1.31-505.fc22 @System 26 k
yum-utils noarch 1.1.31-505.fc22 @System 327 k
yumex noarch 3.0.17-1.fc22 @System 1.6 M
Transaction Summary
================================================================================
Remove 22 Packages
Installed size: 14 M
Is this ok [y/N]: N
Operation aborted.
The development of yum is dead. Some plugins are not yet ported to DNF but they will be soon.
Hi Jan, if yum is dead, why then are there still updates made on yum.baseurl.org?
Yum is in maintaining phase but only a critical bugs are getting fixed (for RHEL only).
they should have kept the name as yum, which is an easy command line to remember. DNF is not a word, harder to remember.
you can use dnf-yum package having symlink /usr/bin/yum to /usr/bin/dnf
Can I please, pretty please suggest the informal name of DNF be Donut Fork in honor of the name Yum and Homer Simpson? LOL
Oh just found /usr/bin/yum-deprecated. Just symlink to /usr/bin/yum and everything works finally again
As of September 10th, 2015, dnf (from EPEL repo) does not work on CentOS 7.x (it used to work, previously). Yum does.
If you mean this bug then it shoudl be fixed in libsolv-0.6.14. Otherwise, report it, please.
they should have kept the name as yum, which is an easy command line to remember. DNF is not a word, harder to remember.
Roblox Hack | Agario Hack | Pixel Gun 3D Hack
Why not keep the name as yum? I didn’t understand it either.
because otherwise users would expect it to be compatible with yum Python “API” and that would break silently user scripts.
As of September 10th, 2015, dnf (from EPEL repo) does not work on CentOS 7.x
we are working on the fix, We need to update RHEL dependencies of DNF first.