I think Drew makes some good arguments here, in particular the one about mediation and users vs developers as groups with different interests.
This is an extremely bad argument. “Universal package managers are complicated” yes, true, “so everyone should build from source” no, that’s harder, and more complicated. Package managers were introduced for a reason, one of which is that it’s almost impossible to reliably uninstall software installed from source, not to mention the yak shaving operation involves when there’s dependencies.
The fundamental problem with binary package managers is that they solve the problem of “every program installed is a global variable that potentially affects the operation of the OS in non-trivial ways” by proposing a solution for globally managing any installed software, which necessarily is slow-moving and complicated.
This is not usually how users see things. Installing a web browser is fundamentally a different type of operation than upgrading the version of python used to run system scripts or replacing the window manager. Those are deep, cross-cutting concerns that affect the system and need to be synchronised.
The version of python I use for writing web applications is not a central concern and shouldn’t be treated as one.
Not everyone has the savvy to git clone;make;make install either. If we want linux to be more common place we need something straightforward like flatpak or appimages. Most people just want apps to start reasonably fast to get work done and storage is cheap (or at least was getting cheaper) so they aren’t gonna care. It would also be easier in the phone space thats happening. Compiling on a pinephone sounds like a chore cause its not that powerful and how much battery would I use to do that? Its better to have a native package but better than nothing. For a power user it doesn’t matter, its not necessarily for us (even tho we could use it)
I wouldn’t go that far as the “guy with a computer”, for example in the case of gnu+linux phones, and gnu+linux non desktop (mobile). There are several apps needing to be adapted to the mobile form factor and touch screen, and plain lack of apps as well, that mos probably flatpak or similar are required on gnu+linux phones.
But I truly dislike the bunch of stuff one gets installed, when installing any flatpak or similar package, both, other flatpak packages, plus what each package itself carries within. It’s way bloated in my humble opinion.
As an Artix/Arch user, I prefer AUR packages, and I even prefer AUR requiring building, over the binary (*-bin) ones, so that I get system libraries being linked, and the right built packages. And only if there’s no option (mainly unavoidable proprietary/closed apps) then I go with AUR binary packages. But if only available through flatpak or similar, then I prefer looking for an alternative SW/app.
Besides the bloated way of that kind of packaging, there’s some sort of centralization. Although there are different flatpak repos, for example, there’s sort of a “central” one, where you find most of the stuff, and then you go to other repos offering some things you don’t get on the “central” one, and if you don’t like their packaging policies, then as usual, go have your own and package yourself, I’d guess… Distros, having their different policies (not just packaging ones):
- vanilla vs making many changes
- rolling release vs. periodic releases
- only free SW vs. free separated from non free vs. not caring at all
- single packages when possible vs. splitting everything when possible
- having a social sort of contract vs. not caring
- focusing on security vs. other focus
- focusing on privacy vs. other focus
- graphical installation vs. CLI installation
- toolset and tooling choices in general
- musl vs glibc
- guix vs apt vs yum vs pacman vs xbps vs …
- enterprise focused vs end users focused
- business oriented vs non profit oriented
And the divergent policies adopted by different distros grow beyond those ones. Such variety can’t be compressed into a single solution fits all. And if you’ve heard pretty influential and vocal open source guys challenging that diversity, and particularly the ability to building the SW differently, I suggest double thinking what that really means, and how that would affect different users, having divergent policies affinities. I, for example, would prefer to use gnu+guix, but given the current hw assigned to me at the office, I can’t be as free/libre SW focuses as I’d like, but I still try preferring as much free/libre SW as possible (slack and zoom are necessary evils in the office for example)…
So this reach diversity, in my mind is good and needed, and having several people building stuff is also good, since having just a few, with unique and common policies, might become dangerous…
Just another opinion, not exactly the same as the one from the “guy with a computer”, but my opinion aligns somehow with theirs.
This guy really managed to write a whole page on package managers without talking about UX
I think all of these arguments are really bad, and I’m someone who hates universal package managers.
“Fragmentation is not an issue”
t seems, they all agree that all of the different packaging formats and managers are a problem. However, is it really so?
Well, duplication of effort is always a downside.
As a developer, by simply using a free licence, you can just sit back and let all of the distros build binaries and do all of the work for you.
The whole complaint being made is that this doesn’t always happen in a timely fashion, and even when it does, it requires a lot of work to be done by each of those distributions.
“There is no need for universal package managers”
Yet, there is a universal package manager that has been around longer than even traditional package managers. BUILDING FROM SOURCE! Many people forget that all of their software is a git clone, make, and make install away from being installed.
I wish it were that simple. In practice, most projects are much harder to build than that. Many use build systems other than plain make such as CMake or Meson and Ninja or GNU autotools (and every project that uses autotools has different levels of intermediate files committed so different commands are needed to build it), and you’ll need to install whatever bespoke build tools they have. I almost always run into arcane error messages that can give me a lot of trouble even as an experienced Linux user and programmer. This is especially true if you’re on a distribution (like anything Debian-based, in other words most newbie distros) where header files are in separate packages, so trying to build anything will give you errors as if you have nothing installed.
A story I always share when this comes up is of my GTK patch that fixed a GObject Introspection annotation (affects generated bindings for other langauges). I spent twelve fucking hours trying to compile GTK and failed. I gave up and submitted the patch without having seen a successful build (it got accepted).
Again, I am an experienced Linux user and programmer. If even I have so much trouble compiling programs from source, expecting anyone who doesn’t have my skill set to do it is crazy.
“Universal package managers are inefficient”
Flatpak, Snap, and AppImage are just not as fast as conventional package formats. Try using any modern version of Ubuntu, and just see how slow their Snaps are.
I have never noticed them being particularly slow, either to install or to run, though I can’t comment on Snap specifically as I’ve only used Flatpak and AppImage.
But, that isn’t really even the worst part. Because of the nature of universal package managers, they require much more space than traditional packages. Every single app, instead of sharing the dependencies of all other apps on the system, is bundled with all of its dependencies. This can add gigabytes of space to many apps, and slow down older HHD’s.
I mean, sure, reducing space requirements is noble, and universal package managers probably take up a little more space (I haven’t analyzed it myself). But it’s far from a chief concern in a day where even low-end drives have hundred of gigabytes of capacities. And as for " instead of sharing the dependencies of all other apps on the system" - blaming static linking is a serious mistake. The space impact of static linking is not a large cost and it easily makes up for it with its advantages in simplicity and reliability. I would blame dynamic linking for a lot of the headaches we have with packaging and compilation. Dynamic linking introduces the need for complex dependency resolution algorithms, tying each executable to a huge amount of environment it has to carry around in order to work, breaking the portability of programs and crowding your package manager output with obscure libraries you’ve never heard of and shouldn’t have to.
While it may take longer to install, it is much faster
took way too long to figure out what this was trying to say (also does building it yourself actually lead to binaries being noticeably faster? i always thought that was gentoo koolaid)
I don’t know very much about this topic, but I think that building a binary yourself can be faster because it can make optimizations involving non-standard CPU features (distro packages have to be compiled without these because the user’s CPU might not support the extension)
Removed by mod
I disagree with the one, especially with the arguments, that I found weak.
The Article ignores some advantages of universal package mangers and ignores some shortcomings.
As others stated, building from source is not a package manager. It does not manage dependencies, it can be very tricky, it takes a lot of time. If you build from source, you have to install dependencies, often manually. Exotic languages and exotic build scripts can make compiling really time-consuming. Uninstalling is also very complicated. That’s what package managers are for.
The stated arguments are only true for free software. I use some closed source software from time to time and I would like to have it up to date.
Speed of UPAs are a problem, but it is a solvable one. It is not inherent to UPAs, that they are slow. It usually arises as trad-off from sandboxing. From a user’s perspective, I like to have sandboxed applications. AppImage applications are AFAIK not sandboxed and usually comparably fast.
From a developer’s perspective, I would like to push out updates fast and don’t rely on some package maintainers. If I publish a new version, I want that all users get that version ASAP. Debian stable release cycles are just too slow for end-user software. I am a bit envy of the fast update cycles of android play store packages. I wish this would be the new standard in terms of fastness (of pushing updates) and sandboxing.
I want to conclude with an example. GURPS Character Sheet is a software that I like to use. It did not have a fedora packge and installing via alien or compile the sources were a bit of a hassle. Thankfully the developer release an AppImage and now updating and installing is just a lot more simple.
