Live data from Hacker News

Yum is dead, long live DNF

dnf.baseurl.org

51–60 of 128 posts

Re: Yum is dead, long live DNF

#51
post #5

Earlier quoted context omitted.

It would have been better to switch to zypper. Both dnf and zypper use a SAT solver for very fast depsolving. Yum and apt don't and both have very slow depsolving. Zypper also directly supports rpm, and would have unified the package managers on Fedora, OpenSUSE and the enterprise Linux distros RHEL and SUSE.

Is "very slow depsolving" even relevant? In my experience that part of installation and remove is a very small part of the overall installation or removal time and goes by so fast I've never really noticed it. Even if dnf and zypper are 1000x faster than apt there, that alone wouldn't convince me to use them.

> Is "very slow depsolving" even relevant?

Try upgrading from major versions and seeing what happens.

It's absolutely relevant

Re: Yum is dead, long live DNF

#52

I may be a sentimental old fool, but I feel a vague sense of sadness at the removal of yum. Seth Vidal, the original author of yum (or, the fellow who forked it from Yellow Dog Updater, and made it yum), was one of the sweetest, brightest, and most helpful developers I've interacted with in my long history with Open Source. He was killed a few years back when he was hit by a car while cycling, and yum has never quite…

Be careful out there...

http://www.redhat.com/en/about/blog/thank-you-seth-vidal

http://www.wral.com/man-charged-in-durham-hit-and-run-that-k...

Re: Yum is dead, long live DNF

#53
post #46

Earlier quoted context omitted.

You can also use `aptitude`, available on both Debian and Ubuntu. It addresses your complaints and it's the first package I install.

It gets so incredibly slow when you have aptitiude around apt around dpkg. Its a minor complaint, but when pacman does everything I want and is probably a tenth the codebase of either yum, zypper, dnf, or apt, then I'm content.

I don't think aptitude is built around apt, but even so, I haven't noticed performance issues.

Re: Yum is dead, long live DNF

#54
Linux is a horrible mess. The more I try to do with it, the more the mess reveals itself. Wayland vs X11, Python 2 vs Python 3, init vs systemd, ifconfig vs ip addr, these are all examples where as a new user you have to learn the new and the old system just to be on a level playing field and it's is far, far too much.

Re: Yum is dead, long live DNF

#55
Yum is "as dead" as one might think Fedora 22 is "production ready!" The reality is RHEL 6, RHEL 7 and many other distributions use Yum and they are not going to go away anytime soon.

Re: Yum is dead, long live DNF

#57
post #54

Linux is a horrible mess. The more I try to do with it, the more the mess reveals itself. Wayland vs X11, Python 2 vs Python 3, init vs systemd, ifconfig vs ip addr, these are all examples where as a new user you have to learn the new and the old system just to be on a level playing field and it's is far, far too much.

Simply put: nonsense.

Re: Yum is dead, long live DNF

#58
post #49
post #41

Earlier quoted context omitted.

Syntax isn't really the problem, given that one could easily write a wrapper around pacman, or apt-get, or dnf/zypper (at least for the subset of common operations supported by all). The problem with pacman as a package manager is that it simply does not have the features needed by fedora or debian. With the infrastructure given by Arch there is basically no way to have automated upgrades without potentially breaking…

Arch always posts breaking changes to its mailing list. If you are complaining about the bleeding edge part, that really has nothing to do immediately with pacman as a package manager, you could always pull a Manjaro with real package introspection to keep tabs on incoming software. The only real missing piece of pacman is that there is no distinction between a feature and security / bugfix update. But then you shoul…

To be clear: I also am an Arch user (albeit not exclusively). I'm not complaining about the bleeding edge part (from your answer I get the feeling you already had similar discussions, with people complaining "upgrade X broke my system"). What i was driving at is the fact that pacman, as it is, does not cover the whole use case of other distros.

Would you take debian, with its three branches, and move it to pacman? No, because the lack of pinning and differentiation between security upgrates and normal upgrades would wreak havoc ("get a better upstream" is a nice suggestion, but an unpractical one). The same could be said for Fedora (actually, for Red Hat, but Fedora is Red Hat testbed after all).

I could set up my own repository, clearly, it may very well be a good solution, but to me that is not automation anymore. Similarly, there is nothing preventing one from setting up one's own repo of old packages, and reinstalling those. Still, I see the value in having the rollback features inside DNF (call it laziness, if you wish). I guess my comment came out as random pissing on Arch, when what I wanted to point out was that other distros simply have different needs.

Re: Yum is dead, long live DNF

#60

Good to know, thanks Hacker News. Better "dependency solving" is appreciated. Though I stopped using Fedora, I assume this will make it to CentOS eventually.

Baring anything horrible with dnf, I would expect it to arrive in RHEL 8.

It wouldn't surprise me to see it show up in centos-extras for CentOS 7 if someone sees a benefit to it.

Post reply on HN