Live data from Hacker News

Yum is dead, long live DNF

dnf.baseurl.org

81–90 of 128 posts

Re: Yum is dead, long live DNF

#81
post #73

Earlier quoted context omitted.

Everyone should switch to Portage. It's like a superset of every package manager.

The portage ebuild system for describing package dependencies and build procedures is awesome. The portage program for solving dependencies and building packages is mediocre at best—it's slow and too prone to not finding a solution even when the constraints of source compatibility are looser than binary compatibility. The gentoo portage repository of packages is clearly understaffed and orphaned packages are all too…

Correct, the all-around best choice is Exherbo's package management. It is extremely similar to Gentoo (after all, many of us used to work on Gentoo), but I'd like to think it has fixed all the problems Gentoo had.

Portage is not used.

Re: Yum is dead, long live DNF

#82
post #80
post #12

Earlier quoted context omitted.

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…

apt-rpm has been around for more than a decade, and was considered for Fedora back in the day (it lost out due to a combination of lack of multilib support back then, and considerations over complexity). Last time I used Fedora it was available in the repository and worked just fine - I always preferred it over yum, despite also preferring RPM over Deb.

I thought apt-rpm was basically dead, happy to read that it is still around. And yes, I reckon the second part of my comment was wrong, you can have apt on top of .deb .

Re: Yum is dead, long live DNF

#83
post #35

Earlier quoted context omitted.

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 just made my first pkgbuild yesterday and threw it on the AUR. Having come from, first, using launchpad (eech) to using the OBS (blargh) how are pkgbuilds not "the final solution" again? They are incredibly fantastic to write and use.

PKGBUILDs and the AUR are great, but I really wish they had a spot on the AUR page for people to add extra info particular to the that package. For instance, if you come across the package in the AUR 'firefox-toast' (made up example), there is no place on the AUR page to add a description that says something like "firefox built with support for toasters." The only place to describe package customizations is in the name and that's often not enough. You could put it in the PKGBUILD, but it seems people almost never do.

Re: Yum is dead, long live DNF

#84

Earlier quoted context omitted.

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 t…

Apt pinning gives you the same functionality as sticky vendors - though it may be a bit more fiddly to implement (I'm unfamiliar with openSUSE PMs)

Re: Yum is dead, long live DNF

#85
post #7
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.

The lower the stakes, the stronger the feelings. C.f. text editing.

The classic problem of Bikeshedding - http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality

Re: Yum is dead, long live DNF

#86
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.

Because switching just the package manager will yield no benefit at all. Having apt as the common package manager among Debian derivatives is meaningful because those distributions get most of their packages from Debian, so they use not only the same package manager, but also same packaging format, same file system hierarchy, same package names/package splitting. All Fedora derivatives, OpenSUSE and Mandriva(?) would…

Most of APT packages' superiority comes less from the packaging format than the entire philosophy surrounding them, most especially in the case of Debian, Debian Policy. Quite simply, so long as I stay within distro, the quality of Debian packages greatly exceeds those of RPM packages (long-standing direct, multiple-instance observation of Debian, REHL/Red Hat, CentOS, Fedora, and Suse systems).

Some of the benefit also derives from the packaging format itself. The ability to unpack DEBs using nothing but shell tools (busybox within a Debian system's pre-boot ramfs is sufficient and has been successfully used by me -- Red Hat loses in this instance by using a ramfs shell that's both 1) larger than Debian's dash and 2) doesn't offer interactive use -- it's a scripting-only shell, FML.

Joey Hess at one time had a detailed comparison of various packaging systems. He's pulled it apparently due to political / fanboi bickering, which is a shame. He's author of 'alien', a tool for converting between packaging formats.

But Policy (and fucking enforcing the fucking hell out of it) trumps.

Source: 18 years' use of both distros and many other Linuxen. 30 years' experience on further Unixen.

Re: Yum is dead, long live DNF

#87

Earlier quoted context omitted.

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

As mentioned, in server land, servers tend to be rebuilt rather than upgraded. In workstation land, major versions don't upgrade that often.

When I do an apt-based dist-upgrade, the long part of the upgrade is not the single-or-low-double-digit seconds it takes to solve the deps, but the download and installation of the new packages.

Re: Yum is dead, long live DNF

#88
post #79
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.

Incidentally, what package manager are you using on Windows/OS X?

Not the author, but I use brew.

Re: Yum is dead, long live DNF

#89
This is what happens when you have too many half employed CS graduates. They have enough free time to keep forking stuff and changing it to put their name on it, instead of fixing the old software of even overhaul it, only to create more management nightmare for serious IT business.

Re: Yum is dead, long live DNF

#90
post #29

Earlier quoted context omitted.

Not only that, but it sounds like someone can just add a solver to apt, whereas repackaging the entire linux ecosystem to use a different format is going to be a bit more difficult.

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?
Post reply on HN