> Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8).
That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro.
Different distros come with different goals. If you take a "super slow but secure" distro, it will be slow and secure. If you take a rolling distro, you get updates very quickly but it has drawbacks. It depends on the use-case, but going for a "slow and secure" distro and then building tooling to work around that choice ("nevermind, I'll ship new and less mature software anyway, statically linked") seems to defeat the purpose of the distro... right?
Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work).
But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I use is closed source so that's not even an option.
The only real option is Docker (or Apptainer/Distrobox etc), which sucks.
The fundamental model of "we'll just ship all software that exists; all software is open source" that most distros try to use is just fundamentally wrong.
Snap and Flatpak are trying to fix that but in my experience they aren't remotely ready yet.
With traditional Linux distributions like Red Hat, you can sometimes take a package from a newer release (or something like Fedora) in source form and rebuild it for your release. When it works, it's literally just one command, which does everything to give you a binary package. If there is some problematic patch, you can often take it out, but also put in patches from the old version. It's usually documented enough to make it obvious.
It's usually straightforward with end user applications, such as bash or git or ruby. Things more likely to be tied to the rest of the operating system, such as SELinux or PAM, are less likely to work. If there are dependencies to things that is release dependent, it's not worth the bother.
Maybe you can argue you don't want to "become a packager", but someone has already done the work for you and you don't need more than superficial knowledge about the system to do it. In most distributions, source packages aren't harder to install than binary packages.
> And no I obviously don't want want to become a packager.
That's where I disagree. It's not that hard, and if more people did it, more software would be packaged. Actually I am yet to find a library that I actually need and that is not already packaged and maintained by someone from the community. Then I could finally maintain one myself.
To me, you're basically saying: "I don't want to learn and commit to maintain a package for my distro, because reason, but I am fine spending time with all that tooling that I say "sucks" (Docker/Apptainer/Distrobox)". That's what I don't really get. There is a solution that works well (for me, at least): package the software that is not already available yourself.
> Some of the software I use is closed source so that's not even an option.
I would not want to maintain a package with proprietary binaries that I don't own, that's for sure. But if you need to, you can. As long as the author distributes binaries for your platform, it's not much harder than making an open source package.
I agree with essentially all of this, and I really think the barrier to entry for packaging should be lower. It was deeply helpful to me while learning Linux to be able to write a Bash PKGBUILD, maybe 20-40 lines, to have that clear structure and ease my own update process, while also making it available to others on the Arch User Repository and learning from comments others left. These days I can whip up a simple PKGBUILD for a simple project I discover in just a minute or three, and it led me to so much experience handling build issues and software dependency structure.
I would leap for joy to see Red Hat or Debian or even Gentoo make inroads here, but I haven’t looked closely enough and recently at Debian, and .ebuild files hurt my brain. I do believe I recall Gentoo requiring more work to get my packages available and listed anywhere.
Yeah I do agree, I find Arch's PKGBUILDs and Alpine's APKBUILDs much easier to write than e.g. a debian package. Not that the debian package is impossible, but it's not as straightforward.
Well we'll have to agree to disagree on that, but I think if you told most people that the normal way to install third party software for Linux was to become a package maintainer they would rightly laugh you straight to the asylum.
> That's what I don't really get.
The reason is that Docker, Apptainer etc are much easier than creating packages for all the dependencies of the software I want to run. Multiplied by the number of distros I need to use. Pretty obvious no?
It is pretty obvious indeed, coming from what I get is your point of view. You seem to believe that you have to become a package maintainer for all the dependencies of the software you want to run. But I think you have this wrong.
Take it like this: in the current state, I am struggling to find a single interesting library for which I could become a package maintainer for my non-mainstream Linux distro, because there always exists one. Maybe not in the core repo, maybe only in the community repo. But still: I don't maintain a single package today, because I haven't found one that I use and that it not already maintained by somebody else.
Really, if you decide to create packages for all the dependencies of the software you want to run, congratulations: you have just created a new distro from scratch. But even most new distros don't do that :-).
In other words, there are way more developers than libraries that are worth being depended on. So even if we wanted to, not everybody can maintain a single package. There are just not enough packages out there for that, by very, very far.
That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro.
Different distros come with different goals. If you take a "super slow but secure" distro, it will be slow and secure. If you take a rolling distro, you get updates very quickly but it has drawbacks. It depends on the use-case, but going for a "slow and secure" distro and then building tooling to work around that choice ("nevermind, I'll ship new and less mature software anyway, statically linked") seems to defeat the purpose of the distro... right?