Graf Zahl wrote:I'm not that worried about intentional breakage but about the inevitable bugs that will always happen. With all these libraries we are pretty much in the same situation as with operating system updates, just that you don't just have one point of failure, but many. In certain ennvironments you cannot afford that some application breaks unexpectedly because another one needs to have a certain library updated. The point of self contained packages is to minimize this inteference.
One of the points of my post is "this doesn't happen nearly as often as you think it does." Sure, if your requirements are that this can not happen at all then there's not much else you can do but hold everything constant. However I think most people don't really understand the implications of holding everything constant, since they'll happily pull the latest every time they build their container or whatever without actually vetting the changes. It is amusing how something can help 100 times without being noticed, but one failure and people shy away.
That is of course ignoring that once you take rolling distributions like Arch out of the picture, the odds of a random update breaking anything accidentally is minuscule since distros like Debian and Ubuntu don't change versions after release. Which is why I related the situation to XP/Vista, if it's going to break it's going to break during the distro version upgrades. (Side-note: After having used CentOS at work for the last 4 years I've come to learn that Redhat doesn't take version freezing quite as seriously as Debian. I believe they have a document listing packages that will never be rebased, but I can't find it at the moment.)
Another way of looking at this is why don't we recommend that every mod be distributed with the GZDoom build that it works with? And we're a community that actively tries to find edge cases to exploit.
Graf Zahl wrote:I think there's a reason why macOS app packages are self contained and normally do not depend on random libraries being installed. The Linux way is the polar opposite of sandboxing, which seems to become more and more popular as a security feature.
I'm not sure I understand which part of the app bundle you think makes it better than the way Windows or Linux apps are distributed. Keep in mind that withing the Linux filesystem hierarchy it's perfectly valid to throw your specific versions of libraries into /usr/lib/gzdoom/ and then set that as the rpath in your binary. Then your custom versions will take precedence over the system ones. Of course package static analyzers will complain since it's not following the distro guidelines of "just rebuild the world" but it is technically valid and correct.
In any case though flatpak is the closest to a macOS bundle. I have to make a correction to my last post, I did find out that flatpak does have a single file export and import, so it is possible to distribute them outside of a repo. From a distance they have similar design in that you build against a common set of libraries (the SDK) and every other resource gets bundled up.
dpJudas wrote:My issue with "the Linux way" is that there's no distinction between system critical, infrastructure libraries and helper libraries. Whether SDL is infrastructure or a helper can be debated, but essentially the QA on Debian often boils down to the attitude or approach of a single developer or packager. Even high profile products like llvm can have disastrous decisions where official packages are rather broken at times. Another example is the freetype2 library that lacked compile time flags for certain types of usages. I have encountered so many such issues over the years that I can't really agree that developers or distros learned their lesson.
Pretty much agreed here. I think with the popularity of containers, flatpak, appimage, snap, what have you, the concept of the distro as we know it is effectively dead, but they don't realize it yet. Well I think Redhat does since Fedora Silverblue is looking to change the model (not sure I agree with their specific ideas, but it's at least trying something). Perhaps it's time to let go of the central mega software repo and instead focus on curating a set of libraries that developers can rely upon.
dpJudas wrote:largely only affected applications that did stupid things
Which was the whole premise.