Graf Zahl wrote:But you also got to deal with the problem when some dependency breaks things without changing its ABI. Who says that SDL 2.11 won't do things that break some edge cases with code that targets an older version, for example? We've seen that happen in the past, most notably with the GME library which we now link statically as a result.
This is where it's important to understand your library's stability guarantees. Most of the big libraries used by everyone specifically avoid breaking applications. The only big name exception I can think of is IJG libjpeg. GME being a small niche library should come as no surprise that the developers aren't as disciplined and static linking is the right thing to do.
libSDL on the other hand, more often than not
fixes issues rather than breaks programs. I could be forgetting something but I'm fairly sure in the entire time that I've maintained the LInux version of ZDoom libSDL has broken it exactly zero times. In complete fairness ECWolf was broken by
2.0.6 like many others due to the audio rewrite (code that GZDoom doesn't use). This got fixed to some extent in 2.0.7 released shortly there after, although ECWolf was more troubled since it has a custom SDL_mixer so couldn't just update to the fixed SDL_mixer. By 2.0.9 though they seemed to have fixed compatibility with the old SDL_mixer. I have since then ported my changes over to the newer code. During all this however I didn't have any issues on Linux either because the change didn't affect my setup, or Ubuntu may have had some patch applied. More to the point though, this is 1 instance compared to the multiple times I've seen SDL updates fix issues (the one I linked at the beginning of this paragraph is the only case I have on hand since it just happened).
We can also look at Doomseeker, which despite dynamically linking to Qt, has not to my knowledge ever been broken because a distro had a newer version than the one I compiled against.
It's not 1995 anymore. Those maintaining serious libraries learned how to not break code, and we've learned to design systems that allow side by side installs of libraries in the case that breakage is intentional. Sadly the latter isn't used to the extent that I think it should (because "security"), but the system is there. If you pick your libraries correctly your app will be about as likely to break as Win32 API applications on Windows in the next release of Windows. Need I remind you about the XP to Vista transition? Given that distros with stable releases tend to freeze library versions and just apply patches as needed, the 2.0.6 bug really isn't any different that what happened there.
Sure there are zaelots that want all dynamic linking or nothing (if I recall correctly GME was originally only statically linked), and the distro maintainers are stuck in the mindset that "we can rebuild the world." There's definitely a more balanced approach that I think should be taken, and in a way flatpak is designed in that manner (with a fixed underlying shared runtime that you build your app off of). At the same time though if you're only using libraries in the flatpak runtime then that binary is basically portable outside of flatpak as well. So in that sense I believe it's a solution to a problem that shouldn't and didn't have to exist, but here we are.
Rachael wrote:At any rate, I really don't see any reason to keep this open. If we do not have someone who is reliable to step up to volunteer creating these packages and making them a part of the official distribution, then the overall necessity of this is nearly non-existent. This whole issue seems to me to just be inventing both the problem and the solution and trying to convince me that it's better than something which has worked for years (decades?) now.
Agreed, if someone is going to do third party packaging then they don't need a ticket to get it done. I don't think flatpak produces a download that we can archive, but if Eonfge gets GZDoom onto flathub then perhaps it might be worth mentioning that it exists under the main downloads with the disclaimer that users should reach out to the maintainer if it's not up to date. I do this on the ECWolf downloads page for the third party builds that I'm aware of.
Edit: Just to drive my point home that these things don't just break all the time. Here's the DRD Team ZDoom 2.6.1 binary from the DRD Team repo running fully functional on Kubuntu 19.04:
http://maniacsvault.net/loosefiles/zdoom_261_1904.png That's the oldest ZDoom binary I have.