Hi, I’m the person who created the PMS snap package and the Plex HTPC one as well, and I did a good chunk of the work porting it to Linux. I’d like to shed some light on the choice of packaging format.
We generally build and package all dependencies for PMS in order to make it portable. This is not viable in the case of Plex for Linux and Plex HTPC for Linux because Qt has several heavy dependencies including arcane Xorg libraries and pulseaudio. Some of which we couldn’t ship our own copy of, even if we built them. So we absolutely needed a container-like format, which leaves flatpak and snap. Snap was an obvious choice for several reasons:
- Prior know-how within the company because of the PMS snap
- Good documentation
- Ubuntu and (most) Ubuntu-based distros (which are still the majority of Linux installations) shipping snapd by default
- Central repository/store to install from (although flathub has kinda become a de-facto standard)
- Good installation experience for users installing from the web or the software store
Due to the association with Canonical, there is a lot of bad will going around against snap as a packaging format. On a purely technical level, it is on-par or better than flatpak and the case against it boils down to one’s views of Canonical. Honestly, I don’t really care about that stuff and made the decision based on the above criteria. This is not a case against flatpak but a case for snap. I personally run software installed with both technologies and I’m equally happy with them.
I am not opposed to also creating a flatpak later on (but, no promises). However, I did look into doing that when I started working on this and the documentation is very lacking. That’s not a show-stopper but certainly makes things much more difficult.
We could also offer an alternative download for an AppImage. However, these are really not that portable as people think. An AppImage is a little more than a glorified tarball and does nothing to shield you from glibc incompatibility. That would be a big problem for us because we build everything in 21.04 and that ships a newer glibc than 20.04 LTS. Which means these binaries (appimage or not) will not run on pre-21.04 versions or other distros with old glibc versions.
I still think it’s possible that we will eventually offer an alternative appimage or tarball download somewhere but we will need to make it obvious that those would be unsupported, I-know-what-I’m-doing builds (again, that’s not a promise).
