Linux @lemmy.ml Tea @programming.dev 2d ago

The wonderful world of Linux package managers

thelibre.news The wonderful world of Linux package managers

One of the strongest points of Linux is the package management. In 2025, the world of Linux package management is very varied, with several options available, each with their advantages and trade-offs over the others.

You're viewing a single thread.

57 comments

pacman is the best and I'll stubbornly refuse to entertain any other opinion. It's in my experience the least likely to just randomly rip the system to shreds. I don't know if it has more through prechecks or what bit I've had debian and Fedora (apt and dnf) rip the system asunder trying to jump multiple major versions in an update of a system that hadn't been online in a long time.

I don't care if jumping multiple releases at once "isn't supported" it shouldn't be that frail and arch will happily update something many years behind as long as you update the keyring.

Even in the event your system somehow does get hosed you can fix almost everything by just chrooting in, grabbing the static pacman binary, and running "pacman -Qqn | pacman -S -" I've recovered systems that had the entire /bin wiped (lol oops moment with a script) and as far as i know apt and dnf have no equivalent easy redo all.
- emerge or gtfo
  
  Anyone looking for the best package manager needs to look only at portage/emerge and nix
- Pacman just does a lot less work than apt, which keeps things simpler and more straightforward.
  
  Pacman is as close as it gets to just untar'ing the package to your system. It does have some install scripts but they do the bare minimum needed.
  
  Comparatively, Debian does a whole lot more under the hood. It's got a whole configuration management thing that generates config files and stuff, which is all stuff that can go wrong especially if you overwrote it. Debian just assumes apt can log into your MySQL database for example, to update your tables after updating MySQL. If any of it goes wrong, the package is considered to have failed to install and you get stuck in a weird dependency hell. Pacman does nothing and assumes nothing, its only job is to put the files in the right place. If you want it to start, you start it. If you want to run post-upgrade, you got to do it yourself.
  
  Thus you can yank an Arch system 5 years into the future and if your configs are still valid or default, it just works. It's technically doable with apt too but just so much more fragile. My Debian updates always fail because NGINX isn't happy, Apache isn't happy, MySQL isn't happy, and that just results in apt getting real unhappy and stuck. And AFAIK there's no easy way to gaslight it into thinking the package installed fine either.
  
  If you want to run post-upgrade, you got to do it yourself.
  
  That’s just wrong. Pacman has hooks, and easy hooks are one of the reasons Pacman is loved. In a normal weekly upgrade I see Pacman run over 30 hooks. I do not think simply not updating user-modified config files is just the bare minimum needed.
  
  I think this boils down to Arch’s philosophy: the users should know their system, and when something could break things, don’t assume things and do it automatically; have the user do it instead. Thus when shipping config updates to a user who had already changed their config, Arch does not overwrite the configs and instead ships the updated vanilla config with a .pacnew suffix. The user is expected to review such pacnews, a process that’s just like normal git merge conflicts when you use the pacdiff tool.
  
  In that specific context I was still thinking about how you need to run mysql_upgrade after an update, not the regular post upgrade scripts. And Arch does keep those relatively simple. As I said, Arch won't restart your database for you, and also won't run mysql_upgrade because it also doesn't preconfigure a user for itself to do that. And it also doesn't initialize /var/lib/mysql for you either upon installation. Arch only does maintenance tasks like rebuild your font cache, create system users, reload systemd. And if those scripts fail, it just moves on, it's your job to read the log and fix it. It doesn't fail the package installation, it just tells you to go figure it out yourself.
  
  Debian distros will bounce your database and run the upgrade script for you, and if you use unattended upgrades it'll even randomly bounce in the middle of the night because it pull a critical security update that probably don't apply to you anyway. It'll bail out mid dist-upgrade and leave you completely fucked, because it couldn't restart a fucking database. It's infuriating, I've even managed to get apt to be incapable of deleting a package (or reinstalling it)/because it wanted to run a pre-remove script that I had corrupted in a crash. Apt completely hosed, dpkg completely hosed, it was a pain in the ass.
  
  With the Arch philosophy I still need to fix my database, but at least the rest of my system gets updated perfectly and I can still use pacman to install the tools I need to fix the damn database. I have all those issues with Debian because apt tries to do way too fucking much for its own good.
  
  The Arch philosophy works. I can have that automated, if I asked for it and set up a hook for it.
- Wouldn't flatpak inherently be less likely to rip the system to shreds?
  
  you have a very limited understanding of flatpack if you think you can use it to install your init system.
  
  Nobody said anything about the init system, though.
- I have absolutely zero experience on pacman, but I could argue the very same with dpkg/apt with the same arguments. The Debian kind, not the abomination Ubuntu ships with today.
  
  as far as i know apt and dnf have no equivalent easy redo all
  
  It's similarily possible (dpkg --get-selections, some sed/cut/awk wizardry to cut unnecessary stuff from the output, xargs to apt install --reinstall on that and you should be good to go, maybe there's even a simpler way to achieve that) with Debian.
  
  But that's just me. I've been with Debian for quite a while. Potato was released 2000, but I think I got my hands on it 2001/2002 and I've been a happy user since. And even if I've worked with pretty much any major distribution (RHEL, CentOS, SuSe, Ubuntu and even Slackware back in the day) around I still prefer Debian because that's what I know and learned over the years on how to fix things if something goes sideways.
  
  I think the missing key there is the independent statically built binary for apt that does not depend on pretty much any part of the base system actually functioning. That's what I couldn't find, is there one and I just suck at Google?
  
  I don't think there's one at least in official repositories. But if you're missing libc6 one might argue that your system is not in any functional state anyways.
- Agreed. The normal pacman CLI does have a comparatively much higher learning curve though compared to e.g. APT. It's not that hard to learn either but when you're scrolling over a long-ass manpage, you do not immediately realize from the headers which whizz by in a flash that -S (alias for --sync) is for installing from repos, -Ss is for searching from repos, -S does not by itself "synchronize" with repos by pulling newest repo package metadata because well that's not what we're "synchronize"-ing with and you have to add the "y" flag, -Su (remember to add "y"!) is for upgrading all packages instead of -U (alias for --upgrade), and -U is for installing a local package. Compare that to the APT/dpkg system's apt install, apt search, apt update, apt upgrade, and dpkg -i.
  
  Admittedly APT does need one to get behind the fact that there are different commands and that "update" and "upgrade" are different, but that's way less to remember (especially since apt is meant to be the interface for everything a user should do) compared to remembering pacman's interesting definitions of database, query, sync, upgrade, and maybe files, while the only definition unlikely to be guessed with APT IIRC is update vs upgrade. You're far more likely to need a pacman cheatsheet than an apt cheatsheet.
  
  But in the end, let's all love libalpm, and the actual code behind that pacman interface.
  
  Pacman has many of the same issues git does. The DX is lacking, but all of the tools you need are there, and it’s reliable despite the lackluster experience.
  
  Good thing there are community frontends.
- I think because other distros don't have half the issues Arch has, pacman isn't as important in keeping the system "stable".
  
  But I understand why someone using Arch would be fascinated by pacman.

57 comments