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

101–110 of 128 posts

Re: Yum is dead, long live DNF

#101

Post by ploxiln »

mpdehaan2 wrote: post #75
raverbashing wrote: post #51

Earlier quoted context omitted.

> Is "very slow depsolving" even relevant? Try upgrading from major versions and seeing what happens. It's absolutely relevant

In server land, it's more common for machines to be rebuilt from scratch (or at least better to do so). Given, I understand some people want "servers like pets" and Linux desktop to be a thing, in industrial applications it's usually not an issue.

I've worked on a large website where all backend servers were running RHEL5. We had pretty good tooling, deployment, config management. We could launch and kill new physical and virtual servers with particular "roles". We did not, however, re-image servers for every deploy. Our deployment/configuration-management would make sure the correct versions of all things were installed, including stand-alone code, services under daemontools, crontab entries, system users, packages, and more.

In most cases, no-longer-specified items would be removed. BTW ansible sucks for this aspect (I use it extensively at a new place) ;)

My point is that, the modern attitude of "you can't trust what's on a server unless you build it from scratch or apply an image" is not the only valid way to do things, and is somewhat defeatist, like we're no better than windows where you can't guarantee that anything can be cleanly uninstalled / replaced. Is your package manager that bad?

Yum being dog-slow was very annoying. Updating all server lists for every yum command was very annoying. I customized various modules and scripts to use "makecache" and "-C" where appropriate, but that was an annoying task. And yum was still slower than I'm accustomed to a linux package manager being.

Finally having a couple of years experience with yum, I can confidently say that pacman (archlinux) and apt (debian) are worlds better. Maybe zypper and dnf make rpm not suck; I probably won't find out for a few years.

Re: Yum is dead, long live DNF

#102

Post by rwmj »

Aloha wrote: post #90
rwmj wrote: post #29

Earlier quoted context omitted.

Red Hat (the company) and RPM (the format) predate Debian, although only by a few months. Also RPM is a much better format than deb, and that's speaking as someone who regularly makes packages using both. I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here: https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...

For those of us uninformed, why is RPM a better format than deb?

Primarily the all-in-one spec file is a lot easier to read and write than the scattered files of deb. Also the build system is considerably simpler and more coherent -- you don't have the mess of dh vs cdbs vs flavour of the month. RPM has a nice language and macro system. It's not that deb is bad, just that when I have to package for both, I find the RPM one simpler and easier.

Here is a relative simple package, done for both RPM and .deb. The RPM spec is 141 lines (excluding the changelog):

http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-to...

The .deb is actually shorter in this case, but split over several files, and uses cdbs which I find infuriating with its lack of documentation and multiple hidden implicit rules. If you have a Debian machine around, try reading the /usr/share/cdbs/1/ files some time. Remember also that for most Debian packages, the files come in a tarball or even a patch, which makes them hard to manipulate without obscure deb-* commands.

https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/vir...

Re: Yum is dead, long live DNF

#103

Post by bad_user »

mmarx wrote: post #71
bad_user wrote: post #39

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.

Since apt-1.0 (basically, since jessie), there's also apt(8), which integrates (most of) apt-get and apt-cache.

Huh, I had it installed and had no idea about it. Looks good :-)

Re: Yum is dead, long live DNF

#104

Post by raverbashing »

ploxiln wrote: post #101
mpdehaan2 wrote: post #75

Earlier quoted context omitted.

In server land, it's more common for machines to be rebuilt from scratch (or at least better to do so). Given, I understand some people want "servers like pets" and Linux desktop to be a thing, in industrial applications it's usually not an issue.

I've worked on a large website where all backend servers were running RHEL5. We had pretty good tooling, deployment, config management. We could launch and kill new physical and virtual servers with particular "roles". We did not, however, re-image servers for every deploy. Our deployment/configuration-management would make sure the correct versions of all things were installed, including stand-alone code, services u…

Thank you.

Today's "continuous deployment" world, that just "tear down and put the latest version" once a week is crazy.

A stable foundation is important, and updating it without breaking everything is needed sometimes.

Re: Yum is dead, long live DNF

#105

Post by rkangel »

rajivmr wrote: post #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.

I assumed that as Fedora is kind of the upstream for RHEL, that RHEL would end up with dnf down the line?

Re: Yum is dead, long live DNF

#106

Post by dmacvicar »

rwmj wrote: post #5
tw04 wrote: post #2

Serious question, because I am admittedly ignorant to the plusses and minuses of the different package managers. If you're going to swap out: why not switch to apt? What does apt lack that DNF is going to provide? This seems like one of those low hanging fruit where standardization across distributions would make sense.

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.

dnf _is_ using openSUSE's sat-solver (libsolv). They reinvented the upper layers.

Re: Yum is dead, long live DNF

#107

Post by Dewie3 »

TheLoneWolfling wrote: post #96
istvan__ wrote: post #24

Out of curiosity, why not fix something if broken? Why is there is always a half baked alternative that has a different set of problems. Instead of replacing what is perceived broken you can just fix it also keeping the good parts. I have several systems deeply vested in in the yum/rpm ecosystem and I see very little chance that a new package manager is going to offer that much new features that I need while keeping…

It's the CADT model of software development, as usual. http://www.jwz.org/doc/cadt.html

It's kind of sad if most programmers think that debugging isn't fun. I thought that was a very large part of the programming process? Or maybe people just do OSS in order to re-balance their programming more to the side of clean-slate programming.

Re: Yum is dead, long live DNF

#108

Post by dmacvicar »

Former libzypp/zypper developer here.

It was not mentioned in the post that dnf is based on the openSUSE dependency SAT solver (libsolv) that was created by Michael Schroeder years ago and that powers libzypp and zypper since openSUSE 11.0.

The dnf developers built a thin layer on top of it, called hawkey, and then build dnf in python on top of hawkey.

One of the biggest innovations of libsolv is not only the SAT based solver but also the .solv format which allows to store package metadata for big amounts of packages in an efficient way and operate the solver directly on it.

https://github.com/openSUSE/libsolv

Re: Yum is dead, long live DNF

#109

Post by acdha »

jetpks wrote: post #97
lqdc13 wrote: post #65

Earlier quoted context omitted.

What? how is this better? what all of this is is apt making users say yes to everything such as config changes. I'm totally fine with that. Sure it's an extra line or 2 when automating, but I don't see it as bad.

I don't know about you, but I'd rather use the tool that I don't have to hack the training wheels off of first when I'm trying to update 100,000 machines to mitigate a critical security issue.

1. Security updates don't add debconf prompts 2. Supporting large numbers of systems is exactly when a persistent local configure database becomes useful for avoiding unanticipated regressions

Re: Yum is dead, long live DNF

#110

Post by mpdehaan2 »

ploxiln wrote: post #101
mpdehaan2 wrote: post #75

Earlier quoted context omitted.

In server land, it's more common for machines to be rebuilt from scratch (or at least better to do so). Given, I understand some people want "servers like pets" and Linux desktop to be a thing, in industrial applications it's usually not an issue.

I've worked on a large website where all backend servers were running RHEL5. We had pretty good tooling, deployment, config management. We could launch and kill new physical and virtual servers with particular "roles". We did not, however, re-image servers for every deploy. Our deployment/configuration-management would make sure the correct versions of all things were installed, including stand-alone code, services u…

> "Updating all server lists for every yum command was very annoying."

This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow. It should also only take (usually) way less than a minute.

> BTW ansible sucks for this aspect

Yep, it's not meant to understand how to remove resources it doesn't know about. That being said, it feels like I've created PHP at times, and I don't mind people not liking it. Many of the ways we have to automate Linux systems (due to lack of structure and API) are kludgy at times, but removal of packages not present in a master manifest seems dangerous to me for various reasons (group installs, tools self-bootstrapping, work happening out of band). Fair enough.

> is not the only valid way to do things

This was not the argument for immutable systems (though I like them), but rather that you need a good disaster recovery strategy and this is likely the best way to handle a major distribution version upgrade.

Minor versions? Continue to do what you do. Major upgrades between EL versions are full of all sorts of fun.

I've typically seem them done with upgrade kickstarts and the like, and you don't get good error reporting there at all when things go wrong. There were some advances in pre-downloading and then doing upgrades but... yeah... not a fan of doing them in automated context.

> " I can confidently say "

Trying to drive it programatically, yum seems much better engineered to me than apt. One example recently (and maybe there's a way in apt to do this) was to be able to select just one repo to use during an update to grab packages from, and I was missing --disablerepo=* --enablerepo=X. But there are a lot of things like that. Config files also seem a lot more capable. My opinion there too of course.

Post reply on HN