Snap and Flatpak vs traditional package management

So what RPCS3 is doing (and what GWE is doing) are all bad ideas… I know Snap and Flatpaks are bad ideas, but don’t see why Appimages are also a bad idea. Though it looks like the consensus is they’re all bad ideas, RPMs and DEBs are better ideas…

This seems off topic, but I’d like to have a discussion regarding it. Can you expound upon why snap and flatpak are bad?

I don’t see why cross-distro packaging is bad for non-system level components.


If someone can confirm it’s off topic, we can create a dedicated topic for it.

1 Like

Confirmed off topic

Moved.

Thanks.

@FurryJackman feel free to change the title.

Appimage as a concept is sound, but I still feel like people don’t like it for some reason and I wanted to open up the discussion about it.

1 Like

Because you end up with libraries packaged in that could contain critical bugs, flaws, etc… that will never get upgraded. The package manager of the system isn’t just there to make it easy to install things, it’s also a security mechanisim.

Right, but I don’t understand (or am just not informed about) your dislike for snap and flatpak.

Isn’t this the same problem with not running sudo dnf update?

Certainly it is, but with a dnf update you are sure that the entire system is updated/patched, and users on the system are not using old libraries known to have vulns. With AppImage type things, a user might be using an old version of say OpenSSL and be open to all sorts of issues, exposing the entire machine. You’re now at the mercy of the app maintainer.

Edit: Just to be clear, I both like and dislike the idea… just pointing out my concerns.

1 Like

I thought that was the primary reason FlatPak uses “base images” that are provided by organizations like Gnome. They stay pretty up-to-date. Maybe I’m wrong though.


To be clear, I definitely see the security concerns. I’m not sure that we need flatpak for everything, just a stopgap.

2 Likes

As far as I am aware you’re correct, but you still then have to rely on your user to remember to upgrade the FlatPak from time to time. FlatPak, etc, are a sysamin nightmare.

1 Like

Unigine Superposition is basically the same issue, because they package a insecure version of Qt and people don’t realize it.

So first things first, I actually don’t know much about the intricacies in how those three formats differ, for an outside person they are the same thing so… there’s that.
Anyway, my thoughts about this that I posted a while ago on the PGP Discord:

  1. Snap/Flatpak/AppImage is OK if you are distributing a software that needs to just work™, i.e. if you’re a software company with customers that use the stuff as daily drivers. An important part is that if you are the software company you need to have the time and resources to update the packages libs for security patches as stated above.

  2. Snap/Flatpak/AppImage are sub-optimal at best for most open source projects I’ve seen so far. From what I’ve seen usually it a) takes ages to even get one of the three working and b) when they are finally done the maintainers of it either lose interest or have real life issues or move on to something else on their crusade or whatever

1 Like

Yes, I think that’s fair criticism, that they aren’t consistently updated. Similar problems with running apps in docker containers. That’s why I use LXC for everything, the native update mechanism always works.

Other than that, the technology behind all 3 is perfectly fine. I do find all the extra mountpoints annoying with snaps, but no biggie.

2 Likes

Just :clap: use :clap: fucking :clap: symlinks

1 Like

It’s a damned if you do, damned if you don’t.

Snaps/Flats/Aims (App Images) are a great way to bundle, for instance, games or other software that is “done” - it’s not going to be developed any more. It’s done and dusted. Bugs and all. Now you just want it to work with minimal fuzz for as long as humanly possible.

But most software is never actually completely done - like most FLOSS. For those, snaps are not a good solution, and actually hinder development for a lot of people.

If you need shit to just work forever choose one distro version and stick to it as long as humanly possible. It is very rare that you need the latest and greatest of everything, but if you do the more unstable rolling release distros are probably a decent fit instead.

Sometimes I just wish some people would realise a lot of the latest and greatest in the Linux world are development releases not yet fit for the masses. But yeah, not happening. :slight_smile:

1 Like

I think it’s part of the chroot or something. I do find them annoying.

1 Like

flatpaks are managed by the software manager on the system the same way RPMs are, so if the user isnt updating their system it doesn’t matter if there are flatpaks installed or not. Fedora 30 already uses them, no one notices as they work as expected and update with system updates.

From my understanding flatpaks also generally link to a repository so installing standalone flatpaks (like for example installing chrome on Fedora) will install the repo as well for updates. Correct me if im wrong.

The consensus is RPM bad for userland flatpak good. That’s why everyone’s moving towards them, slowly.

2 Likes

This is true.

1 Like

Is there any case where you would use a snap when a native package is available? To me, they’re a better alternative to either downloading binaries and dumping them in /opt or compiling from source and trying to keep up with updates manually.

I’m not sure why anyone would install a snap of something that was easily available via package manager.

I certainly wouldn’t, no. These things are primarily useful for portability, you don’t need a package for your distro, you just need snap support.

Some containerization makes sense, when there are a bunch of dependencies. For example, the Ubiquiti Unifi controller, they don’t quickly update it for newer releases so you have to deal with broken dependencies on an older version of mongodb. I don’t use the docker container myself, but it makes sense that lots of people do.

1 Like