Tue 12 May 2026

I was thinking about Arch's pacman this morning, mentally noting once again how insanely fast it is compared to all of the other package managers I've used.

So, I thought I'd put out an informal package manager tier list, based primarily on speed, and just going on my own general impressions, no actual metrics (who do you think I am, Roy Longbottom!? 😆).

Oh, I guess could use TierMaker to make this post meme-worthy, but WHY? It'll just be plain text (html + markdown), as usual. PLAIN TEXT IS KING!

The Tiers

Explanation/Details

S Tier

Pacman

Dude, pacman is the G.O.A.T. What else can I say? I literally don't know how they managed to make their package manager that fast. There are many good reasons to not pick an Arch-based distro, but pacman is not one of them. It's utterly fantastic. Well, ok, I can ding them a little for the obtuse syntax:

> Master, what is the difference between pacman -Syu and pacman -Syyu?
Grasshopper, when you understand this, you will understand all things.
> But master, how can I understand this?
Grasshopper, you must become one with the Mountain.
> Uhhh, thanks, I guess I'll just read the manpage and keep some crib notes
Yeah, that's pretty much what I did, tbh.

A Tier

Debian apt

apt-get, apt-cache, apt-cdrom, and now just apt are the O.G. package managers. When rpm was inciting existential horror in sysadmins (more on this later), apt-get was the friendly, competent package manager for-the-people.
It's not as fast as pacman by a mile, but it's plenty fast enough for most purposes, especially when you have good mirrors selected.

B Tier

Disclaimer: There isn't a lot of difference between the A Tier and B Tier on this list. Consider the A Tier just a highlighted section of the B Tier, if that helps.

FreeBSD pkg

From what I can tell, FreeBSD's pkg is the friendliest of the BSD package managers, although I seem to recall NetBSD's pkgin being rather friendly as well. Its syntax is pretty similar to apt, so it's quite easy to pick up and use, and the speed is pretty close to apt's, as well.

NetBSD pkgin

Admittedly, I haven't spent much time in NetBSD (yet!), but I do recall pkgin being pretty easy to use. I don't think it's as fast as FreeBSD pkg, but I'm giving it a B because they also provide packages for other operating systems through their ports, which is a great service.

NixOS nix

I've never run NixOS, but I used nix briefly on Debian as a secondary package manager. It seemed quite capable, and the fact that it can be installed on any Linux is pretty nice!

Solus eopkg

I also only ran Solus for a relatively brief time, but I recall eopkg being decently easy to use, and I don't recall having any complaints about its speed, so I'll leave it here. The only complaint I had at the time was that it was stuck in Python version 2 long after it had been out of support, but I'm happy to report that (IIRC) that has now been corrected.

C Tier

Fedora dnf

dnf ("DaNdiFied yum") is pretty easy to use, and capable. It's not impressively fast, but it definitely gets the job done. No complaints.

Fedora/RedHat yum

yum ("Yellowdog Updater iMproved," borrowed from YellowDog Linux, an early RedHat derivative for PowerPC architecture machines, particularly Macs) was a marked improvement over rpm

flatpak

flatpak definitely gets the job done. Like any secondary package manager, it does use up a lot of disk space, but it's a nice way to keep graphical (and now even a handful of command-line/TUI) programs up-to-date when using a very stable distro like Debian. It's not impressively fast, and some of the textual output formatting is incredibly ugly to the point of being useless, but it does work well, acceptably quickly, and reasonably efficiently, for what it is.

Homebrew

I used Homebrew a lot on Mac OS X back in the day to install all manner of command-line utilities. It's pretty neat, but I've only used it once on Linux (on Solus), because I'm concerned with security and trust when it comes to my software installation sources, and I'm not familiar with how they vet the software they include.

Still, it's a good option as a secondary package manager, especially for command-line packages.

OpenSuSE zypper

Before handing out any criticism, I should laud the OpenSuSE project for providing packages for so many other distros through their OpenSuSE Build Service. That's a really cool service to provide, and I've taken advantage of their packages on Debian.

As for criticism, I actually don't have much. zypper is acceptably quick (though I wouldn't call it fast), easy to use, and stable. I only wish the command was a little shorter. I usually do a...

$ cd /usr/bin
$ sudo ln -s zypper zyp

...on my OpenSuSE machines, just to make things a little shorter (zyp up instead of zypper up or even zypper update). 😅

Python pipx

pipx is a killer feature for python-based packages (that are included in PyPI, of which many, many are). It's an excellent secondary package manager, and is how I usually keep a handful of very useful utilities (such as edir, rokucli, sncli, termdown, toot, and yt-dlp) up-to-date across nearly all of my machines.

pipx has a major advantage over pip in that it keeps the modules it installs confined to "venvs" or "Virtual Environments" so they do not conflict with python packages provided by your OS's package manager.

D Tier

Arch yay

To many, the AUR is a killer-feature for Arch Linux and its derivatives. The last time I was on Arch-derivatives, I made extensive use of yay ("Yet Another Yogurt"), an AUR helper, which helps to semi-automatically package up AUR pkgbuilds and install/update the packages via pacman.

But these days, I'm a bit wary of user-contributed packages, so I'm not using or recommending the AUR, or AUR helpers like yay. The only thing I use the AUR for now is finding useful packages (on the website), which I will then download, build, and install via the git repos.

Python pip

I'm only putting pip in the D Tier because it can theoretically conflict with your OS's python packages, but that's honestly pretty easily reversible, as it installs everything under your home directory. Still, it's better to use pipx in almost every circumstance.

F Tier

cargo

The cargo package manager for rust-based software isn't bad, per se. It's reasonably easy to use, and fast. But the build process for rust is so resource-intensive, I'm knocking it down to F, and I do not use it anymore.

Sorry, not sorry. 🤷‍♂️

OpenBSD pkg_add

*Sigh*, ok, listen...

OpenBSD is dear to me. It's pretty close to my very favorite BSD and one of my favorite OSes of all time. I massively respect what the OpenBSD team is able to do with the resources they have (as opposed to the light-cigars-with-benjamins-while-dreaming-up-more-bullshirt-to-inflict-on-Linux-users Linux Foundation).

And, pkg_add has actually gotten a decent bit faster in the past couple years.

But dang, it slow. Just trying to find out the size of a package (including the dependencies that it would need to install) can take minutes. I'm guessing it's actually downloading the entire package and pre-staging, but not installing it? Perhaps there's a lack of metadata to calculate the potential size without actually downloading full packages, or perhaps it's just how it's written, and it can be made much faster? I honestly don't know. But pkg_add is easily the least endearing quality of OpenBSD.

I'm not complaining, though. I'm just... quietly sobbing. 😅

snap

Oy gevalt.

Canonical, what are you even doing, bro?

You're shoving trackers into all your websites, you're shoving packages into snap instead of .debs, you're forcing all of your job applicants to be interviewed by Shuttleworth and pass his personal vibe check before being hired, you're... you're...

You're a mess, fam.

Redhat rpm

rpm is not a bad package format. Nor are the rpm utilities themselves particularly slow. But rpm is barely a package manager. It will remove a package upon request, it will display info about installed packages, and it will install a package if given a file... or just fail to do so.

rpm doesn't know anything about "available" packages. It has no repos. It just deals with its own database of installed packages, and whatever package files you give it. That's it.

Memories of trying to set up RH Linux servers circa 2002 and schlepping CD after CD into the drive to try to find the right package that has all the dependencies needed to install package X... It sucked, and that's why rpm get's an F. In this case, "F" is short for "Frankly, barely even a package manager."

Category: Tech Tagged: BSD Computing FOSS (Free and Open Source Software) FreeBSD Hobbies Humor Linux Non-religious post Polemic Productivity UNIX