This site is significiantly improved by visting through the Gemini Protocol.

Why use Gemini?See the Gemini Quickstart to get started!


“universal” package managers

↩ go back to index

“universal” package managers

september 1, 2021

There's been a lot of discussion on my fediverse timeline about flatpak and a need for a “universal” package manager so you don't have to package your program for 1,500 distros. While I agree with the sentiment, I cannot possibly understand why anyone would think that flatpak, snaps, appimages, or docker is the way to go. I'm mostly focusing on flatpak because that's what the recent discussion has been about but believe me the other container programs have just as many problems (snap in particular is far worse than flatpak).

issues

they ain't universal

The biggest issue is that the “universal” package managers are in no way universal. Want to use flatpaks or snaps or appimages on BSD? Fuck you use a better OS! Want to use snaps or appimages on a systemd-less and/or glibc-less Linux? Fuck you use a better distro!

IMO if you're claiming to be “universal” you should work on all POSIX systems; but ⅔ of the most popular platforms **don't even work on all Linux distributions**. Even if you don't care about *BSD or OSX or illumos or Haiku or Minix or any other system support I see no way they could possibly be called universal when they don't even support Linux.

many, many, many security flaws

You may say “well you're arguing for installing directly onto the system, how can containerization be less secure than that?” And you're right, containerization is more secure than directly installing like a traditional package manager, but it also provides a false sense of security.

In traditional package managers it's heavily emphasized that you need to trust the packagers for your distribution—that's a big reason why I've used Debian on my servers before but not ubuntu, I don't trust canonical. On the AUR there are innumerable warnings saying “Don't trust the packagers! Verify the PKGBUILDs yourself before installing!” On the other hand, flatpak portrays itself as a secure sandbox.

From the first paragraph of the wikipedia article:

It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system

snap has similar marketing. I will give points to appimage though, they don't falsely market “security” or “isolation” and focus purely on the “simple packaging & distribution“ and “no installation” features.

Unfortunately flatpak is not secure at all; I personally would never run a flatpak on any system I consider important. It both lacks security by design and the developers have also shown callous disregard for fixing security issues.

Here's a good write-up of flatpak's security issues circa 2018, plus an updated write-up from late 2020. Also talks about non-security issues such as how it doesn't integrate properly with the desktop environment and doesn't even support Chinese character inputs.

the benefits either aren't benefits or aren't unique

The purported benefits provided are either not benefits at all or are in no way tied to flatpak & co. despite what people may say.

Firstly I'm just going to pick apart this quote because it was copied and pasted by someone a thousand times in a fediverse thread and it irritated me:

Apart from offering a single bundle for different Linux distributions, Flatpak offers integration to the Linux desktops making it easier to browse, install and use Flatpak applications, e.g. the Gnome Software Center can be used to install a Flatpak.Flatpaks are forward compatible i.e. the same Flatpak app can run on the next releases of a distribution without changes.Run-time dependencies are maintained which can be used by the application.

Apart from offering a single bundle for different Linux distributions…

This is the only real benefit I acknowledge for all these things. Even then, there's nothing saying you can't just pick one package manager and make packages for that, and then expect the community to maintain packages for their pet distros.

Sourcehut only officially supports Alpine's apk package manager, all the other repositories are community-maintained

DevKitPro exclusively distributes through pacman and yet they still support apt-based distros, Mac OS, *BSD, even windows.

…Flatpak offers integration to the Linux desktops making it easier to browse, install and use Flatpak applications, e.g. the Gnome Software Center can be used to install a Flatpak.

Why is this unique to flatpak? There is objectively nothing stopping traditional package managers from having a GUI for browsing, I see no reason why that's supposedly something only flatpak offers. In fact, KDE has a package–manager-agnostic app store called Discover:

Discover is your new one-stop shop for all things app- and addon-related. Designed from the ground up to be easily handled by users as well as easily integrated for distributions.

It doesn't even introduce another competing format (See XKCD 927), instead it integrates with the existing package manager for your distro to provide an app-store like experience.

Flatpaks are forward compatible i.e. the same Flatpak app can run on the next releases of a distribution without changes. Run-time dependencies are maintained which can be used by the application.

Wow, it's almost as if that's exactly what dynamic linking is! I just install a new version of the library and as long as it's ABI-compatible I can use it with all the existing programs! Unfortunately flatpak doesn't do that so you're usually left with very outdated libraries that often have multiple CVEs open for them. If you are going to bundle dependencies at least statically link so you get a performance boost rather than dynamically linking but without any of the benefits of dynamic linking.

lose individuality

In case people can't comprehend this, a big selling point for a distro is what's in its repos. If you expect people to use flatpak everywhere then you're not going to have one repo anyways because you need ultra-stable, security-backported repos for Debian; regular stable repos for a whole bunch of distros; bleeding-edge repos for Arch and co.; repos that don't depend on systemd (not even possible for snap and appimage); repos that don't depend on glibc (not even possible for snap, appimage, nor flatpak); and then you're just ignoring even more special distros like Gentoo or Slackware that don't even use traditional package styles.

And then you're including proprietary software in your repos. You cannot expect a large portion of Linux users to use your repos if you have proprietary software in them at all, even if they don't need to install it.

an alternative solution

Why does a universal package manager need to use containers or any of that shit? If you want to make something universal, in my experience you have to make it simple and easy to implement everywhere rather than adding layer upon layer of complexity. *BSD isn't likely to implement Linux cgroups any more than Linux is likely to implement *BSD jails; and if your implementation relies on the intricacies of one or the other then it's going to be neigh-impossible to port it to any other system.

Here's a random package solution that I just came up with. A package is a .tar.gz archive of the following structure:

This is the most distilled and generic you can possibly make a package as far as I can think of. It would probably be trivial to write a package manager for pretty much any *nix system that uses this format.

While it would be much simpler to just have a compressed mock filesystem like Arch packagesᵃ, the reality is that most distros have different standards and preferences on where to place files and to maintain the portability of the manager it'd be better to let each distro configure where each file is placed. In this format, each type of file is in a generic folder so each OS could install it in the proper spot. Systems that use `/usr/bin` could install files from `bin` there, while systems that use `/bin` could instead install binaries there. If the program *needs* files to be in a specific location (configuration, etc.) then they'd be placed in a mock filesystem in the overlay directory.

Libraries and other dependencies should either be statically linked or listed in a dependency list in METADATA.txt, rather than potentially bundling horribly outdated libraries with the package.

The metadata files are stored inside the tarball to make distribution easier. With this scheme you only need to distribute one comprehensive archive instead of the package archive and a bunch of sidecar metadata files.

[a]: Structure of the packages used by pacman and the Arch Build System

↩ go back to index

add a comment!

view likes and comments

contact: alex [at] nytpu.com

backlinks

-- Copyright © 2021 nytpu - CC BY-SA 4.0

Proxied content from gemini://nytpu.com/gemlog/2021-09-01.gmi

Gemini request details:

Original URL
gemini://nytpu.com/gemlog/2021-09-01.gmi
Status code
Success
Meta
text/gemini; lang=en-US
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.