- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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 must log in or register to comment.
I’m just happy my boi nix got a shoutout.
I love having a packages file and a lock file, both user-specific rather than system-wide, offering reproducibility, stability and a good, central place where I can see what I did to debug.
In 2025, the package manager and frequency of updates are the only real differences between most distributions. I’ve been enjoying Flatpak for years now and hope it continues to build momentum. It offers the possibility of shared effort between distributions who depend on legions of volunteers constantly updating debs/rpms/whatever.
It feels like one of the last hurdles to eliminate so much of the duplicated effort associated with all these distributions.
Amen.
Flatpak is literally installing a second Linux distribution on your machine, just without a kernel. All the dependencies right down to the C library are installed in the Flatpak environment. This why you can run a Glibc Flatpak on a musl distro.
Microsoft could support Flatpak “natively” on Windows. It could use the same kernel and GUI glue that WSL uses but you have no need of specifying a distro or getting to the command-line. The experience could just be that you go into Flathub, install and remove apps, and everything would just work.
Apple could do the same with macOS.
If they did that, Flatpak could be a universal app distribution method on all three systems. Devs would only have to create and maintain a single version if they wanted.
Microsoft will not do that of course. If it really was a brainlessly simple alternative application store, they could OS/2 themselves and loose control of the platform.
Too bad though. It would be cool. No reason it could not be done independent of Microsoft of course but it would never be as popular if it was not built in.
Thanks for posting that was really informative i was always intending on learning more about package managers at some point. What I wonder is when you want a package and it’s available as both a dnf package and a flatpack which one should you chose?
Native then Appimage then Flatpak. Security is the same in the end, but in Flatpak with extra steps, while Flatpak has a huge framework that can fail too.
Shame they didn’t mention that homebrew is a security nightmare and will happily download maliciously modified code
Edit: omg then the author claims flatpak is better for security?!? It has the same nightmare security issues.
Shame they didn’t mention that homebrew is a security nightmare and will happily download maliciously modified code
That’s so true, I was missing this part! With homebrew you’re at the mercy of whoever put the package out there, much like with installers (and nix to be fair)
Edit: omg then the author claims flatpak is better for security?!? It has the same nightmare security issues.
LMAO no‽ Flatpaks can be verified, and you can choose not to install unverified flatpaks (which you should!) They are also containerised pretty well by default, in case they’re malicious!
Don’t mind me, being a casual user since 2014 taking down notes as I’m reading the debates in the comments.
But I finally found out why Steam kept crashing. Snap broke it. I forced it to run as a flatpak, and now it works exactly as intended. Literally what made me finally switch from Ubuntu to Mint.
Linux Mint is based on Ubuntu. Wouldn’t it be better to go for one of the distributions everything else is based on? Debian or Fedora?
Mint doesn’t natively shove down snap down your throat though 🙂
I thought Fedora didn’t either? That’s a Ubuntu exclusive I think (not sure!). In any case, its a couple lines on the terminal and it’s gone.
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.
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.
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.
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_upgradeafter 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 runmysql_upgradebecause it also doesn’t preconfigure a user for itself to do that. And it also doesn’t initialize/var/lib/mysqlfor 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.
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
pacmanCLI 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
aptis meant to be the interface for everything a user should do) compared to rememberingpacman’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 apacmancheatsheet than anaptcheatsheet.But in the end, let’s all love libalpm, and the actual code behind that
pacmaninterface.Pacmac 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.
@Aatube @LordKitsuna @Tea There are some things I’d like pacman to do automagically that it doesn’t, like update the list of archives when they change. Tried to install a package the other day and it kept throwing 404 errors because I had a stale list of archive sites. It didn’t tell me that, it didn’t fix it automatically.
Always run
-Suybefore installing new packages. That’s how it is supposed to be.
Pretty good article, went into some technical stuff, which surprised me as in Linux world I’m used to articles discussing changes in wallpapers between different distro releases :D
Wallpaper, yeah, there’s a lot of that going around. The main feature discussed with the recent new release of apt discussed colour as the primary new feature. No mention of any actual substantive changes or reference to the impact on apt-get et al., or even a link to the detailed change log.
Synaptic all the way
I’ve tried in the past flatpak packages, they are terrible in many senses the proponent (vast majority AFAIK) don’t say, among them:
- They create huge static binaries
- One gets many libraries embedded in the static libraries or local static libs to the package which are often repeated among many static binaries, even the same version of them. This is totally avoided when building against dynamic native libraries.
- When installing a pletora of static dependencies for a package, lets say liri, a bunch of the stuff it requires might already bi installed natively in your system, but they need the static deps locally part of the package.
- Care must be applied, there are statistics available about abuse on vulnerabilities infection on pypi, npm and so on, this no different on these packagers repos/hubs.
Good that they provide an alternative way to install packages not available in your distro repos, but for that user repositories building against native libraries are a much better option, like AUR in the case of Arch, and even their binary packages coming from other distros or from upstream might be even better than those universal static binaries providers.
There are political aspects involved in the past claim from the proponents, and it’s that in their view gnu+linux echo-system should become like the windows one, where everyone company or org (to them doesn’t matter) should be able to provide their binary packages, and then there’s no reason to think of anyone being able to build their staff.
There’s a tendency actually on providers on those hubs, to ignore problems on people who tries to build their stuff on their own, claiming they only support those universal packages. Which to me it’s dangerous, since it goes in detriment to the ability to build and distribute the software, which might not be due to licenses, but rather practical reasons. This might actually be against the licenses they use, but now a day who cares, right, it’s available on that packager repo…
Lastly one argument provided in favor of the apps coming from those universal packages is sandboxing. But there’s firejail which can be install on most gnu+linux distributions, and comes with profiles for a pletora of apps, and if sandboxing is not enough, it can easily be combined with apparmor, or if you prefer selinux might be used… No need for those universal packages to have a sandboxed experience.
One final note, so far gnu+linux has been characterized by having a diversity, which is good, that diversity offers people options to choose from, and a lot of different solutions for different purposes. Not so long ago the claim was that it was not good, that meant fragmentation, and fragmentation is bad for adoption and maintenance. I see it the other way around, this diversity allows for choosing for what aligns better with the user intends, like easy to use, or rolling release, or as vanila as possible, or as up to date as possible, or as hardened as possible, etc, etc. Systemd is another example of this universalization intended. Perhaps some distros prefer to be a shell for systemd and get packages just from universal packages, that’s bad news to me.
Of course having universal packagers present an oportunity for corps and orgs to also provide stuff on the gnu+linux platform, but in my mind the best would be for them to offer free/libre and open source software, that would build on any system and be provided by any packager that wants to offer it. Though I believe that to be too idealistic perhaps. Jeje.
To understand how to interpret these complaints, we need to understand that Flatpak works by essentially installing a second set of libraries for your apps to run on. The apps run in a container (much like Docker) on top of these libraries. Flatpak uses the kernel and display server from your main distro but otherwise Flatpak is like a second distro unto itself.
So, if you only install a Flatpak app or two, it is very true that they will require quite a large number of support libraries to run (just like running one app on your distro is more distro than app space wise). However, as you add more apps, they they resuse the libraries that the first apps installed.
Because Flatpak installs all its own support libraries, the apps run the same on all distros (which is the point).
So, Flatapak does duplicate the libraries on your system out of necessity. Because your Flatpak apps does not use any of the libraries from your host system. However, they are only installed once inside the Flatpak environment.
The comments about vulnerabilities are neither here nor there. You have to trust your distro. You have to trust Flatpak (as a second distro). Both are subject to vulnerabilities and supply chain attacks but neither more than the other. Flatpaks are technically after as the container environment they run in “sandboxes” your Flatpak apps. In practice though, they require enough permissions that the sandbox is trivial to escape. So not much difference.
There’s a good deal of misinformation here. The main part being disk space. While it is true that flatpak apps will take up more space, it’s not nearly as bad as you think it is. There is a lot of really good optimization going on under the hood that you don’t see. Dependencies are de duplicated. I’m no expert on it, but I believe that dependencies also have delta changes from one version to the next.
Regarding apps not supporting building of the source, you should get over that or do the work of supporting it yourself. Open source is a hard, usually thankless job.
cons:
- dependencies
we get it and don’t care. they’re convenient and work well.
