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

[Brisse]

Creak
IIRC, GNOME already has plans for such GUI settings in gnome-control-center.

[DrYak]

DrYak well rolling distros aren't as stable as regular distros. They need a bit more legwork to keep it stable.

I've been a former Gentoo user at work (lab's standard distro-to-go in one of the Uni I've been at) and I see what you mean.

But since openSuse Tumbleweed, I've been pleasantly surprised at the amount of efforts that suse devs have put into making it a painless experience and at the quality of the result.
It has become an as light experience as using the release based openSuse Leap.

And 3rd party repos are not very user friendly.

Again the Suse effort upon Yast "1 click install" have made it wonderfully simple in my experience.
They have a nice search engine, which clearly separate small scale personnal repos and larger scale projects, and if you're to lazy to manually add the repos to yast, there's a "single click" solution that can automatically add all the necessary repos and install all the corresponding dependencies.

The whole distro experience is designed with strong 3rd party repo support in mind (seems to me that it stems back from when it got bough by Novell and had to switch to US legislation, which is much harshed regarding multimedia codec patents - rendering 3rd party repos a necessity for keeping multimedia functionnality to european-levels : packman was practically born from that).

I don't have personnal experience with, but I've also heard/read positive feed-back about Ubuntu (Reportedly it's a breeze to add 3rd party blob drivers to support NVidia hardware).

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

Nope, indeed. Rolling distros are for people wanting *the latest version ever of everything*, as I've said above.
(Though as I've said in this comment, openSuse Tumbleweed is in my experience a surprisingly good quality rolling distro with very little brokage. On the other hand everything seems simpler than babysitting a Gentoo rolling install :-P ).

If you want a stable base and only a few newer applications, that's what the whole purpose of 3rd party repos is.

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.

I would never be advocating self-compilation for people who aren't into it.
If you're not into compiling newer versions, maybe switching to a distro with a more vibrant community of 3rd party repo could do the trick ?

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.

In my opinion, RHEL/CentOS is one of the hardest to get better/newer software. They have this concept of software collection (basically, their take on what Conda's environment or HPC's environment modules are doing), but it looks to me not as good as the later.

(Been having a couple of tiny problems to get exactly that : python programs requiring slightly more recent versions of modules).

2.
Sometimes the application requires just a single library in a higher version, which is already a non-trivial problem.

Note that, though I'm not advocating to self-compile, the comment I've written about packaging also apply there :
soname changes with ABI.

So, in your example if libtiff 4.0.4 and 4.0.3 are compatible, you can safely overwrite one with the other. (and lock the package in your package management system to avoid a security upgrade accidentally over-writing and downgrading it).

If 4.0.4 introduce a new incompatible ABI, the soname will change and the file will have a different name (like libtiff.so.4) and can safely be deployed alongside your distro's library (libtiff.so.3). Your distro's software will still pick the correct version when running.
( ^--- which is also exactly what a 3rd party repo would be doing behind the scene)

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.

This is in my opinion the main push behind opensuse strongly developping it 3rd party distro integration (Packman is *the* answer for any audio/video answers).

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.

Actually nope. Not at all. Codecs (libav, libx264, etc.) are typically the kind of libraries that change ABI extremely frequently (mostly adding new functionnality).
Thus "updates" end-up being differently named packages each droping a different library with a different so-name.

The problem is only correctly cleaning up, and avoind (or locking) the older that you compiled against, even if they show up in the "orphaned" or "unneeded" section of your package manager.

This is unfortunately a problem for unofficial repositories, developed in free time.

In a small project like "home:dryak" on OBS, yes definitely.

On a large scale project whit lots of ressource like packman : nope, they have a decent amount of community workforce to handle this.

And again, regarding 3rd party repo, in that situation, you'll end up simply with having RPMs "libavfilter5", "libavfilter6" and "libavfilter7" all installed simultaneously because each one is a dependencies to a different software package.

Seriously, try to build the latest PiTiVi on EL7, then you'll know what I'm talking about.

I'm on opensuse Tumbleweed, I already get PiTiVi version 0.999 for free in my base :-D