What should a lay user know about Linux app packaging?
I’m enough of a Linux lay user that I’m not even sure if I’m using the right terminology in the question (feel free to tweak it if needed!). Here’s what I mean:
I’m running Pop!_OS currently, and I have at least one app installed via each of the following methods:
- Deb app from the distro repositories
- Deb deb downloaded from program website
- Flatpak app downloaded from Flathub
- AppImage app downloaded from program website
- Snap app downloaded from the Snap store
As someone who doesn’t really know or necessarily even care to know what’s going on under the hood, these all pretty much work identically for me (with the exception of AppImage which doesn’t integrate into my regular programs menu, and the standalone Deb, which requires manual updating). In fact, for most of the programs on my computer I couldn’t tell you which one they’re sourced from. They all just run like they should.
I’ve looked up differences between all of the options and usually end up finding conversations that go well above my head and get deep into technical details. My question here is basically aimed at cutting through a lot of that depth: what is the important, need-to-know information about these different methods of installing apps? Is there anything I should be aware of if all I’m really going to be doing is running them as a standard, non-power user? Also, if an app is available via multiple methods — is there one that is preferred/better/safer/superior/etc.?
IMO, the important parts are capabilities and trust.
Distro packages :
Flatpak :
Snaps :
AppImage :
So with these facts in mind, I personally much prefer Flatpak, I think it's the future of Linux packaging. If not available or possible within the restrictions (for example, a system library or terminal utility), I'd go for distro packages. I avoid snaps and appimages at all cost.
Deb app from the distro repositories -- preferred, tested, stable, safe. You should use those 99% of the time. Depending on your use case, it's not that hard to use software exclusive from the official repos.
Deb deb downloaded from program website -- second preferred
Flatpak app downloaded from Flathub -- if unavailable or recommend by the developer to get more recent versions. Not as well integrated to the system in general
AppImage app downloaded from program website -- practical but I prefer the repositories
Snap app downloaded from the Snap store -- kinda like Flat packs, championed by Ubuntu. Kinda controversial.
Flatpacks and Snaps are somewhat integrated but fairly independent from the system, this creates problems some times. The file sizes are bigger too. Appimage always work but it packages everything in the file so downloads can be huge.
I never had much luck with Flatpacks, to be honest.
For more info on flatpak/snaps being independent, look into sandboxing - it's not particularly relevant to what you're doing and you don't really need to care about it, but it's what your phone and browser do for security.
I know someone who runs Discord with flatpak because they don't particularly trust it in regards to privacy, for example.
I have switched to Fedora Silverblue which uses flatpak for almost everything. It's pretty nice tbh and certainly the future of the linux desktop. There are just a few edge cases which need sorting out. Things like drag/drop files tends to not work but I assume this will all be fixed soon.
We really need to get past the era where you music player has access to your session token for your bank.
The main two considerations I have are convenience and security. I weigh these hand-in-hand.
My hierarchy for where to get software is as follows: Distro > Dev package => Flatpak > Source > Appimage.
If it's an Electron app, they'd better have one of the first three, or the fourth (this has never failed, either). Apparently these are the hardest to build/package according to many distro guidelines/from source with different versions of stuff.
Your distro should always be your primary source both for security and system stability. Running an Ubuntu-based distro, you'll also not need to go as far out of your distro for current versions of many applications (LibreOffice, Firefox).
I, personally will try to find a dev-provided .deb package, but these can fail. Spotify, for example, requires old libraries, and I'll just use the flatpaks for Discord and Spotify anyway. Spotify provides a snap, but I don't use snaps for reasons I'll explain at the end. I don't worry too much about sandboxing, but I also make sure I'm using officially-supported flatpaks made by the app's developers, in the case of Discord or Spotify, I'm reasonably sure nobody's going to do anything to bring the wrath of Spotify or Discord upon themselves with their distribution of an unofficial package.
Sanboxing is relevant here because many Flatpaks and Snaps simply don't configure themselves to do it securely, giving themselves full access to your home filesystem in the name of convenience. I generally am okay with it, but with the awareness that these programs could just vomit on my home directory one day, even if it's quite unlikely.
If it's not available as a flatpak, and the .deb won't run, and it's open-source, I'll compile it. This is trivial, and I recommend learning how to do it. Everything should go to /usr/local, instead of /usr, the default for most configurations, so you have a low risk of breaking anything. When in doubt, go slow and triple check. I think every Linux user should be able to do this, because it's basically playing with godmode, but also requires the responsibility of a system-local deity.
AppImages are my last resort because they don't automatically update. Even sourcecode, as most of it is in a git repo these days, is trivially updated with a quick pull. Often developers will have flatpaks and/or snaps and/or AppImages.
*About snaps: I don't like them because in a world of open source software, Canonical insists on using a proprietary backend for their snap distribution framework. This may seem hypocritical coming from somebody posting from Windows, but it just doesn't sit right with me. Flatpak is a packaging standard, and flathub one of many potential repositories for flatpak packages. I'm more comfortable using a framework whose backend I could dissect or self-host if I had the knowledge, interest, or need to, at least with open source software.
Regarding compiling from source - it's been a very long time since I've needed to do that, but when I did, I'd always make a deb and install that. It's a bit more work upfront but makes removing/upgrading/etc things easier down the line.
That's a nice guide! I've been trying to do that lately, but I find some stuff just works better if it's unpackaged (Supercollider 3.11 + sc3plugins, as an example I had to
make installrecently).I must observe that compiling from source is not trivial for the regular non techie user. It is often necessary to gather dependencies that are not always obvious, there may be conflicts, and developers often do not provide support or complete instructions. Besides, it requires familiarity with the command line. Compiling from source is very much for enthusiasts and/or intermediate users.
I think of it as an almost necessary skill. You can use Ubuntu and never do it and never need to do it, but I feel like it enriches your experience when you encounter that one program that is only source-available or is simply not packaged for your distro. I've also never had issues with support compiling software that isn't packaged for a distro. It's usually unofficial packages that cause upstream issues in my experience.
The only reason I'm comfortable claiming that it is "trivial" is because it's not a particularly difficult process to do or undo.
Compiling from source can be certainly helpful, but I maintain that it is not trivial and not recommended for beginners and most regular non-technical users.
Another thing to note is that the fragmented state of package management you're dealing with is pretty much just a Debian / Ubuntu problem.
On Arch, for example, packages are all build around what are basically Bash scripts. This means regardless of the distribution mechanism (be it a .deb file, a .tar.gz file, or even just source code), the package manager can process it and check for updates. Trust-wise, you have to trust the developer of the application (a given) and the packager, but package scripts are so small that it's easy (and recommended) to read through them before installing.
But to answer your question:
.deb files are the original distribution mechanism for Debian and Ubuntu. Installing them through the official repositories is preferred. You'll see a lot of older programs distributed this way. It's fine, basically.
Flatpaks are a Debian / Fedora answer to not having a distribution model like Arch, with some sandboxing thrown in. They run everywhere. Flatpaks can be uploaded either by developers or the Flathub maintainers, which unfortunately can lead to stagnant or abandoned packages.
Snaps are very similar to Flatpaks. Controlled by Canonical (the company behind Ubuntu), they integrate into systems a bit worse than others. I'd probably avoid these if I were you.
AppImages bundle together (almost) everything needed for a program to run, but don't have a real way to update themselves. This makes them good for games, scientific programs, and not much else.
Flatpaks are not a response to the AUR at all nor are they made for Fedora or Debian. Flatpaks are a response to Linux fragmentation and security concerns. They're made to distribute once, for everyone.
Flatpak is an answer to not having all the software, which the AUR solves for Arch. Arch doesn't need Flatpaks, basically, because maintaining (noncritical) packages with
pacmanon a rolling-release system is trivial.My impression is that sandboxing is a secondary goal.
No.
The AUR does not solve Linux fragmentation nor does it have "all the software". Software compatibility is not being solved on the AUR. If the package requires old libraries or specific versions of software, you're screwed.
From the perspective of a app developer, the AUR will screw you over. You may not want to support every distro and fix tons and tons of distro-specific bugs but I guess forcing them to do so is a "solution".
There's also moments where the AUR just ships broken shit. For example, the "Authenticator" application was packaged for the AUR but it's broken because it requires patches on top of GStreamer and the package maintainer doesn't want to do it. Who gets the blame? The application developer. This is hostile to developers.
Furthermore, no, security was not a secondary goal. It is core to the design. You don't accidentally create a sandboxing system and permission system and push for dynamic permissions like portals if it was never your goal.
People deserve to be able to protect their files, to be secure, to be able to have newer software than your distribution supports. Developers deserve to not have to fix tons of distro bugs they never intended to support.
I am not claiming that the AUR solves Linux fragmentation. It does solve the "this program isn't available for my distribution" problem (for those running Arch, of course) with the eighty thousand packages existing packages and by how simple it is to package a new program (some examples are in my parent comment).
Arch is a rolling release system - to require specific versions of libraries is antithetical to its design. Regardless, for the (very) few programs that do, it's easy to lock programs to a version because of how easy it is to package software in the first place.
Distro-specific bugs are bugs. I certainly don't think and haven't observed there being "tons and tons" coming from Arch because, again, the nature of the package management system means that Arch-specific patches rarely exist. Your Authenticator example is the exception, not the norm, and in fact has already been fixed by kind and constructive people.
The primary goal of Flatpaks is cross-platform support. The status of other goals comes down to opinion - from my perspective, sandboxing is a secondary goal that built off of much of the structure that needed to exist to distribute packages in the first place. To be frank, I don't think the sandbox is good enough to warrant calling it a primary goal.
But this is the reason it exists so you can't call flatpak an answer to the AUR if they don't solve the same problem..
This is not "very few", most if not all games do this hence why the steam runtime was made all the way back in 2013 and is being upgraded even today to make it impossible to rely on the host because some game developers relied on the host rather than steam runtime which resulted in game bugs. Most programs require specific versions for API/ABI compatibility. They just happen to work with newer versions.
They are distro bugs. Developers should not have to deal with every bug that is specific to a distribution.
I'm not only talking about Arch here, I'm talking about application distribution in general. Arch is just one way this may happen.
Wrong bug, I'm talking about this one where the developer was told that they were in the wrong for patching Gstreamer for their usecase and that they should "drink some baking soda".
Sandboxing is not a secondary goal, the permission system and creation of portals proves that this is in fact, an important goal for the project.
This is literally FUD.
Let's go through it quickly :
Read the permissions and modify them as you wish. It's still a major improvement compared to traditional packaging. The goal is to remove all those permissions over time as people transition to portals more and more but for now, certain programs don't make sense without those permissions. It's not hard to modify the permissions either, you can use Flatseal.
So like basically all distribution models. Completely useless commentary. This is not a flatpak bug, this is a flathub and packaging software bug.
To be very clear: the AUR is an Arch-specific feature. It cannot and does not solve Linux packaging fragmentation because it's exclusive to Arch. What it does is solve the effect of packaging fragmentation for Arch users by having every piece of the software under the sun available or easily packageable. Flatpak aims to solve this "not all software is available" for non-Arch distros like Debian or Ubuntu by trying to convince every developer to use their shiny object (while Arch just makes it safe for random people to take care of packaging).
Disagree. While open-source games may do this, they make up a minuscule fraction of distribution packages. That doesn't matter, anyway - you may have missed the part where I described Arch's system of version locking. Games are a poor fit for package managers, regardless - I suggest elsewhere in the thread to use AppImages.
And I'm talking about Arch. Debian's weird downstream patch system is none of my concern and not what I was addressing. It seems Flatpaks maintained not maintained by the developer (these exist, before you say otherwise) could end up suffering the same problem.
Read my words - I never said it wasn't, I'm saying it's not a primary goal! "from my perspective", "I don't think" - how, possibly, could I make it any clearer that in absence of an official project statement, the specific ranked order of goals is left up to opinion?
My view on Flatpak's sandboxing stands - not restricting
.bashrcwrites and the like is not what I'd expect out of a project that has security as its primary goal, which is why it appears to me to be a secondary goal. I don't care that it's better than nothing. I don't care that fine-grain permissions can be tweaked. That's not what I said, and you know it.I seem to recall having other conversations with you specifically that have gone down this non-constructive, intentionally-misquoting route, so I'm breaking it off here. I hope my earlier comments were helpful or insightful to someone else.
Flatpak is not made for any distro in particular. You can totally use it on Arch.
PKGBUILDs are not safe, it can totally just delete your entire system. You've said yourself that people should read what they do so I find this a bit strange.
Doesn't version locking result in other packages needing the same library being unable to update or does Arch have a modular system? It's my understanding it doesn't have one but I could be wrong.
I think there is a misunderstanding between our interpretations. You said it was that Flatpak was an answer to the AUR, I disagree with that. It's all I care about when it comes to Arch specifically.
This is true. I am one of the maintainers so I certainly acknowledge that however Flathub tries to always go for the upstream development being involved whenever possible.
I guess I just don't think a project's goals are someone who's not involved in the project's opinion. I think it can be misleading to say that.
Flatpak packages do restrict
.bashrcwhenever it is possible without being destructive to using the application. The discord package that I maintain for example only has access to"--filesystem=xdg-videos:ro", "--filesystem=xdg-pictures:ro", "--filesystem=xdg-download",and I plan to remove all filesystem access as soon as possible.I don't believe I've said that you specifically cared about permissions but the flatkill article completely ignores that information and you showed it as proof of the sandboxing not being good enough so I thought I'd mention it because I believed it was relevant.
I'm sorry if that's been your experience with me, it's definitely not my intention to misquote people and I try to be constructive. If you feel like it, please DM me to show me where you think I misquoted you, I want to be better.
Snap has a proprietary server, so i prefer not to use those.
another option for these tools that don't get discussed a lot is nix, unlike flatpak and snap and appimage it just downloads the files it needs (no "kitched sink" downloads of flatpak runtimes), it's still is somewhat glitchy but is a nice alternative (it seems to be experiancing some serious growth in adoption), guix is similar but less popular.
Honest question: I've seen several people in this discussion mention that Snap being proprietary makes it undesirable compared to distro packages (such as .deb s). But don't you have to trust the maintainers of the binary distro package servers, too? What does it matter that the binaries are supposedly built from libre / open source code? Logically, they're both subject to the same possibility of tampering server side, and both are binaries by the time the arrive on your filesystem for installation.
It's not about the package binaries, it's about the server-side code itself, which is proprietary. I mostly use flatpak for a couple proprietary apps, but occasionally for OSS, and simply feel more comfortable using a platform that is completely distro-agnostic and fully open source.
A lot of it is trust, and it's far easier, for me at least, to trust an organization that allows people to scrutinize and it's server code instead of a company that is attempting to create and capture a market in open source while locking their code from the open source community.
EDIT: I use flatpak for proprietary software, lol
As knocklessmonster says, this is not about the binaries.
This is about Free Software ideals and power. People want to be able to run their own repositories if they want to. People want to not rely on a specific company for their package to survive and for the time they invest in the technology. People want to hack on the code to improve things.
For people who believe in Free Software, this is never going to be acceptable and for most if not all distributions, this is a threat of corporate takeover.