Most Linux distros come with a package manager, which is responsible for installing and removing packages and all their dependencies. In theory, these package managers help the user, doing the dirty work behind the scenes. However, things can get really embarrassing when we take a closer look.

APT (Advanced Package Tool)

The most popular package manager on Linux is APT, which was popularized by Ubuntu, although it's originally a Debian software that Ubuntu inherited.

Let's try to install this well-known bash script called neofetch on a fresh Ubuntu 24.10:

None
Sure, 36 dependencies to run a bash script… Not to mention these 'suggested packages'

APT says neofetch requires 36 dependencies, but as you can see above, if you download it manually, you'll realize it requires none. What is going on?

OK, maybe that's a very specific issue. Let's try installing the Xfce file manager, Thunar:

None
This is not quite right

We know Thunar doesn't require libxfce4panel or libxfce4windowing, so what's happening here is that Thunar has an optional plugin (thunar-tpa) that depends on libxfce4panel, and libxfce4panel, in turn, depends on libxfce4windowing. So in this case the package manager isn't exactly wrong, however, this highlights how chaotic this whole dependency hell can be.

None
Thunar is totally innocent here

We can go even further by manually deleting these libs, and Thunar will run just fine.

But wait because it gets even worse. After removing Thunar and running sudo apt autoremove (to clean the leftovers), I decided to install Thunar again, you know, just to see how it goes:

None
Orphan packages are common place when using APT

Oh, dear… When we installed Thunar the first time, APT told us it needed to install 21 dependencies, but now it says only 15 are required, which means there are some orphan packages in the system. And folks, this happens all the time. Continuous use of APT increases entropy indefinitely, and given how long APT has existed, it seems no one is willing to fix it.

DNF (Dandified YUM)

The default package manager on Fedora, DNF, is another example of crap software that is clueless about what it's doing. Let's try to install fastfetch on a fresh Fedora 41:

None
A clean system is for weak people, they say

Although it says 10 additional packages are required to run fastfetch, the truth is that it requires zero, as shown by running a precompiled (non-static) version just after canceling the outrageous package manager prompt.

The same issue we saw with APT installing more dependencies than needed when trying to install Thunar happens here as well, with the added bonus of getting an error when calling sudo dnf remove thunar. According to DNF, the correct form should be Thunar (with a capital), although when installing it, there's no problem using thunar (in lowercase):

None
Expecting coherence from crap software is too much — wtf these warnings?

Trying to install LXQt file manager, pcmanfm-qt, is a disaster:

None
Wallpapers, screensaver, terminal? At this point the package manager is probably trolling us

Pacman

Arch-based distros use Pacman package manager, and as expected it's not an exception when it comes to dependency hell. Here's an attempt to install Thunar on a fresh CachyOS 241221:

None
Déjà-vu

Nope, libgtop is not actually a dependency of Thunar. It runs perfectly fine without it. What happens is that libxfce4ui, which is a Thunar dependency, contains an executable (xfce4-about) that requires libgtop. It's interesting to note that Debian-based distros chose to split libxfce4ui into multiple packages, separating the libraries from the executables, alleviating this issue at the cost of creating more complexity.

At this point you might be thinking: 'I get it, sometimes my system will have more packages than it should, but that's a fair price for having applications that just work.' OK, but what about cases where the package manager simply fails to install an application properly, like Pacman's installation of Meld on a fresh system?

None
Did you forget to say the system is not up to date?

What happens is that Arch is a rolling release distro, meaning its repository is constantly updated, with no frozen version of any kind. Because of that, if the user doesn't update the whole system before installing a new package, chances are things are not going to work. In this case, the more verbose parameter -Syu is recommended, instead of -Sy.

Conclusion

Linux package managers have existed for decades, yet they still don't accurately detect the actual dependencies of packages. The process is not reliable at all, often installing more packages than necessary. In some cases, like APT, your system might have orphan packages after a package is removed. In other cases, like Pacman, some applications won't even run because everything is so fragile that the whole system needs to be constantly updated before installing any package. Not to mention annoyances, like DNF accepting a given keyword to install a package but refusing to accept the same keyword when removing that package.

Some attempts have been made to fix this mess, such as Snap, Flatpak and AppImage. Snap is a proprietary joke, Flatpak is the most bloated ecosystem ever created on Linux, and AppImage might work or not depending on the libraries installed on your system. What they all have in common is that they ultimately don't address the root problem.

The fact that there are so many different Linux package managers out there should be a red flag. But the best clue that this whole dependency mess should end lies in the fact that on other operating systems, like Android and iOS, the user doesn't need to have/use a package manager simply because the applications made for these systems contain everything they need to run properly. And that's the correct solution.

Discussion: Hacker News