Spotify Tops Ubuntu's Snap Store Downloads While GIMP Tops Flatpak's Flathub

[Creak]

DrYak well rolling distros aren't as stable as regular distros. They need a bit more legwork to keep it stable. And 3rd party repos are not very user friendly.

I'm rolling with Fedora 29 and Flathub and honestly, it's a breeze to use (only exception being when you have files on another partition, which is the case for Steam for me).

Using Flatpak with Flathub is really damn useful and practical. Much more than the other options, in the end.

[the_scx]

If you really want to have the latest version of open source software, without the hassle of self-compiling, why not simply switch to a rolling-distro ? e.g.: openSUSE Tumbleweed is a very good one, with very rare breakage (a rolling distro doesn't mean a constant compiler-and-debug fest as Gentoo :-D )

Typically, users expect a stable base and a few newer applications. This is not the case for rolling release distributions.

If you don't necessarily want the latest version of everything but a few key apps, why not simply use a specific 3rd party repository (e.g.: Ubuntu's PPA and opensuse's Open Build System ?) not everything are small scale home project by enthousiats that just share a couple of self-compiled packages, some are large collection (see the Packman repository for everything multimedia for suse).

What if such repositories/packages for a given distribution don't exist? Will you build packages on your own? It is not always as easy as it may seem.

1.
Let's say that you have RHEL7 and you are interested in an app based on PyQt5 (e.g. ReText, Anki, etc.). Although EL7 contains both Python3 (EPEL: Python 3.4 & 3.6; RHSCL: Python 3.4 & 3.5 & 3.6) and Qt5 (currently Qt5 5.9), it has too old SIP to build python3-qt5.

See also: https://github.com/scx/retext-flatpa...-a-rpm-package

2.
Sometimes the application requires just a single library in a higher version, which is already a non-trivial problem. Let's look at Rawtherapee. This program requires libtiff >= 4.0.4. However, EL7 provides libtiff 4.0.3, so you have to bulild and install libtiff >= 4.0.4 somewhere (e.g. /usr/lib64/rawtherapee, /usr/lib64/libtiff4, /opt/libtiff4/lib64) on your own. It's not difficult, but it's just the beginning. You also need to pay attention to:
- additional CMake options:

        -DTIFF_INCLUDE_DIR="${LIBTIFF4_INCLUDE_PATH}" \
        -DTIFF_LIBRARIES="${LIBTIFF4_LIBRARY_PATH}" \
        -DTIFF_LIBRARY="${LIBTIFF4_LIBRARY_PATH}/libtiff.so" \

- RPATH:

       -DCMAKE_INSTALL_RPATH="${LIBTIFF4_LIBRARY_PATH}" \

- filtering automatic dependencies:

%filter_from_requires /^libtiff\.so\.5.*$/d; /^libtiffxx\.so\.5.*$/d
%filter_provides_in %{_libdir}/%{name}
%filter_setup

See also: https://github.com/Beep6581/RawThera...ment-450160092

Creating a flatpak package is much simpler, because you don't have to worry about these things.

3.
Many distributions are quite restrictive when it comes to audio-video codecs. Fedora leads the way here, unfortunately in the negative sense of the word. The same applies to EL. Of course, we have 3rd party repositories (e.g. RPM Fusion, Negativo17) that provide ffmpeg, x264, x265, etc. The problem starts when you need to update one of these components. Then you have to rebuild all the packages that use it. This is unfortunately a problem for unofficial repositories, developed in free time.

See also: https://forums.nux.ro/index.php?t=ms...=3825#msg_3825

This problem doesn't exist in Flatpak, because each application has its own version of ffmpeg.

4.
Sometimes the program is developed for flatpak in mind. PiTiVi's official development environment is flatpak and for a specific release they target a specific runtime/sdk version. Seriously, try to build the latest PiTiVi on EL7, then you'll know what I'm talking about.

See also: https://github.com/flathub/flathub/p...ion_r125766456

[oyvind]

That's annoying indeed, but you can just bind mount the wanted folders, so it's not a total disaster, just a tad unfriendly to the average user

Sure, I could do that, and have done that. But pulling other mounts into the /home namespace comes with its own set of problems. Apps reading from the bind mounted dirs will generate playlists using non-canonical /home/.. paths, backup system will suck up an extra TB of data if I forget to exclude, locate will give duplicates unless configured specifically to exclude, I have to mentally remember that the files are located under multiple prefixes, and use the /home prefix for some apps, app A invokes snap app B with path to a media file using the proper mount point fails, because app B is only able to read that file under the /home prefix, more complexity and config to maintain.

Not worth it, I'll stick to PPAs or just the regular old apt versions, until this issue is somehow resolvable in a simple fashion, like allowing a snap application full access to everything my own user can read or write on the system. I like the snaps I've tried so far, they appeal to me because of easy updates to recent versions and much less dependency hassles. But this problem needs to get fixed for apps working with local files.

[jo-erlend]

like allowing a snap application full access to everything my own user can read or write on the system. I like the snaps I've tried so far, they appeal to me because of easy updates to recent versions and much less dependency hassles.

Maybe use devmode for the time being? It's no more dangerous than using a PPA, that's for sure.

[Creak]

Well, oyvind , I completely agree. I have the exact same problem with Steam. That's why I stick with the rpmfusion's package.

I think an appropriate solution would be to allow specific access rights, per application. I like the sandboxing thing, but I think it needs to be a bit more customizable, on the user land.

[oyvind]

Maybe use devmode for the time being? It's no more dangerous than using a PPA, that's for sure.

Thanks for the tip, I'll try this.

[Creak]

jo-erlend I searched for "flatpak devmod" but couldn't find any result about it. Could you be more specific, please?

[the_scx]

jo-erlend I searched for "flatpak devmod" but couldn't find any result about it. Could you be more specific, please?

Devmode is a snap thing.

Developer mode, or devmode in short, enables developers and users to install snaps without enforcing security policies.

As for flatpak, you have flatpak override.

[Weasel]

Of course it wouldn't be Linux if it didn't have something insane in package distributions, like the sandboxing shit by default, which probably comes from mobile baby land.

[Creak]

As for flatpak, you have flatpak override.

Well I thought flatpak override was a command line that needed to add each time you would run Steam, or to add to the .desktop file, but no, it's merely one command line to enter once and it's all fine afterwards!

This makes Flatpak incredibly interesting because you would have the default permissions and then you could add your own -- like allowing, for you only, that Steam has access to another drive: https://github.com/flathub/com.valve...team-libraries

I guess, later, flatpak will provide some kind of mobile-like interface so that it would request specific privileges only if you use them (like requesting bluetooth access only if you plug a bluetooth controller).

I'm impressed