Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yum is dead, long live DNF

dnf.baseurl.org

Post reply on HN
Print view View original

41–50 of 128 posts

Re: Yum is dead, long live DNF

#41

Post by baghira »

zanny wrote: post #34
lucb1e wrote: post #26

Earlier quoted context omitted.

Why?

I like it way more than apt at least. I don't have to use apt-cache, apt-get, apt-kitchensink to do what I want. Its all just subcommands of pacman. Its like vim vs nano - the later has the commands in the shell, but they aren't nearly as fast or power to use as vim if you take the time to learn it. Ironically, I use nano most of the time because I'm not terminal-locked enough to get vim muscle memory, but I use pacm…

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 the system. The same goes for the AUR: it's great when you know that the user is reading the script and making sure it's not malicious: it's not a model that scales for server (just like FreeBSD ports do not cut it if you have lots of machines), or if you imagine 10% of the computer running Arch (malware bonanza). Still, automating apt-get is messy (and here dnf/zypper do a better job) and building .deb packages and setting up your own repo is too complicated.

Re: Yum is dead, long live DNF

#42

Post by benjiweber »

jlarocco wrote: post #15
rwmj wrote: 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.

As well as being a lot faster than apt, the biggest advantage of openSUSE package management stack to me is that it plays nicely with third party vendors.

Packages have sticky-vendors, so you only get updates from the same vendor unless you choose to switch. Even if another the update is in a different package repository. This means you don't get flip-flopping package vendors when the same package is available from two vendors and they release updates one after each other.

Another example is the tooling around package/repository signing - Letting the user decide whom to trust without making them jump through hoops to manually import keys.

There's also a lot of things in the packaging itself designed to help support third party vendors. Dependencies tend to be configured with capabilities rather than package names. e.g. The kernel provides information about the binary api version which third party drivers can depend on. Third party kernel modules can also supplement/enhance (soft dependencies - inverse recommends/suggests) specific PCI ids so the solver will suggest installing them if available and compatible with your hardware.

In my view debian package management "just works" because the set of packages is carefully curated and tested, there's a high standard of package quality, and everything is available in one place. PPAs can present problems.

The rpm distro ecosystem philosophy is somewhat different. It's impractical to expect a single organisation to package all the software you will ever need, so let's provide tools to help software from multiple vendors to get along.

Re: Yum is dead, long live DNF

#43

Post by hyperrail »

SwellJoe wrote: post #37

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…

> Also, "dnf" is not at all awesome to say out loud, while "yum" is among the most awesome commands to say out loud.

Indeed, to me, saying "dnf" out loud suggests "did not finish," which is the opposite of what you want from a package repository tool!

Re: Yum is dead, long live DNF

#44

Post by amyjess »

baghira wrote: post #12
rwmj wrote: 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.

As far as I can tell the fedora guys wrote libhawkey and dnf to reach some sort of middle ground, as switching to zypper would have implied breaking everything (i.e. all the scripts admins use, rewriting parts of anaconda, etc). The compatibility is not perfect, and in fact a fair amount of people complained (see some discussion on phoronix). As far as the parent post is concerned, to switch to apt would imply switch…

For the record, apt doesn't always imply deb: apt-rpm exists, and it's used by a few distros, including PCLinuxOS.

Re: Yum is dead, long live DNF

#45

Post by amyjess »

warmwaffles wrote: post #31
lucb1e wrote: post #26

Earlier quoted context omitted.

Why?

Because I have been using Archlinux full time for a while now. It's dead simple to make PKGBUILDs and maintain your own packages. Yum and RPM? forget it.

I've built debs by hand before. It's not hard, and it's trivial to automate with shell scripts.

And once you've built a deb, you can use alien to convert to RPM (the only gotcha is that RPM runs preinst/postinst scripts with an empty environment and dpkg doesn't).

(and I say this as a diehard Arch user who came from Gentoo)

Re: Yum is dead, long live DNF

#46

Post by zanny »

bad_user wrote: post #39
zanny wrote: post #34

Earlier quoted context omitted.

I like it way more than apt at least. I don't have to use apt-cache, apt-get, apt-kitchensink to do what I want. Its all just subcommands of pacman. Its like vim vs nano - the later has the commands in the shell, but they aren't nearly as fast or power to use as vim if you take the time to learn it. Ironically, I use nano most of the time because I'm not terminal-locked enough to get vim muscle memory, but I use pacm…

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.

Re: Yum is dead, long live DNF

#47

Post by zanny »

warmwaffles wrote: post #36
zanny wrote: post #34

Earlier quoted context omitted.

I like it way more than apt at least. I don't have to use apt-cache, apt-get, apt-kitchensink to do what I want. Its all just subcommands of pacman. Its like vim vs nano - the later has the commands in the shell, but they aren't nearly as fast or power to use as vim if you take the time to learn it. Ironically, I use nano most of the time because I'm not terminal-locked enough to get vim muscle memory, but I use pacm…

Yes the `-Sy` bit is a bit cumbersome / annoying. I would have much preferred `pacman update -s` and `pacman remove `. When I have to install a font on my machine that isn't in AUR I'll just roll up a PKGBUILD, install it and dust my hands off. Makes it incredibly easy to remove the packages later if I no longer need them.

Its not cumbersome, the alternative is more cumbersome, it just requires memorization. Like I said, zypper is a great compromise, where you could do zypper update and zypper install, or you could do zypper u and zypper i. A bit more intuitive for the newbie but it doesn't make you write words like you're writing a poem in bash.

Re: Yum is dead, long live DNF

#48

Post by SwellJoe »

DAddYE wrote: post #40
SwellJoe wrote: post #37

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…

I never had a chance to interact with him but I share the same feeling. I'm probably too an old fool but I really liked YUM.

I suspect he would have been right out front on integrating these new ideas into yum; he had a long history of pushing yum forward (which is why it became the standard for RHEL and Fedora despite Red Hat having developed one of their own; but, it was clear to everyone, including Red Hat, that up2date was inferior in every way to yum). So, I tend to think if he were still around, we wouldn't be talking about something replacing yum, we would instead be talking about new features in yum. I think it is unfortunate that people felt the need to fork rather than enhance.

Re: Yum is dead, long live DNF

#49

Post by zanny »

baghira wrote: post #41
zanny wrote: post #34

Earlier quoted context omitted.

I like it way more than apt at least. I don't have to use apt-cache, apt-get, apt-kitchensink to do what I want. Its all just subcommands of pacman. Its like vim vs nano - the later has the commands in the shell, but they aren't nearly as fast or power to use as vim if you take the time to learn it. Ironically, I use nano most of the time because I'm not terminal-locked enough to get vim muscle memory, but I use pacm…

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 should be more stringent with upstream to beta test their feature releases better.

Really if you wanted to automate pacman nothing stops you from creating your own custom repo as a gateway to some workstation or server cluster you have and setting it up to use your custom repo exclusively for all packages. It has delta support, does checksums, uses the best compression format available, and is a lot easier to use for custom applications than the OBS or alternative packaging tools.

Post reply on HN