[DIY] AppImage or Flatpak

[monstario]

Can GZDoom's devs consider packaging GZDoom as a Flatpak? It would ease installation and auto-updating compared to downloading .deb from ZDoom website, and would be more secure than adding https://debian.drdteam.org/ repository.

EDIT:
AppImage would be even better.

[Rachael]

If there's an easy and automated way to do it - sure.

But the problem is, like many things that happen in the Linux world, a simple concept is conceived of, then 10 different developers all come up with mutually incompatible solutions and all claim that their's is the best.

And worst of all when this happens, rarely any of those solutions end up being truly user-friendly to the targeted audience.

What's to stop someone from wanting a Docker GZDoom? Or an AppImage version? Inevitably if we do this, one person will want one, then another person will want the other, and they will also have their whole list of reasons why their idea is better than this one.

[Gez]

SLADE has an AppImage and a Flatpak, but both of those originate from pull requests by the people who were interested in getting them.

[axredneck]

https://flathub.org/apps/search/freedoom
This?

[monstario]

AppImage would be great, even better than Flatpak, since it's indifferent to a given distribution (no installation = no system-wide stability issues) and doesn't need to be pushed to third-party repository like Flathub after each update. I'm on Debian Stable and currently stuck with PrBoom+ because GZDoom is not in their repos and https://debian.drdteam.org/ is made on Ubuntu base and thus faces stability risks when used on Debian. The official .deb seems to work OK, but using Ubuntu binaries on Debian is strongly discouraged.

[_mental_]

I'm on Debian Stable and currently stuck with PrBoom+ because GZDoom is not in their repos and https://debian.drdteam.org/ is made on Ubuntu base and thus faces stability risks when used on Debian. The official .deb seems to work OK, but using Ubuntu binaries on Debian is strongly discouraged.

Well, I suggest you to build GZDoom from sources then. No foreign package installation, no mysterious risks, whatever.

[monstario]

Well, I suggest you to build GZDoom from sources then. No foreign package installation, no mysterious risks, whatever.

I will probably just do that, I followed instructions on a VM and it compiled successfully. I didn't mean to sound picky, it was just a suggestion

I too find it strange "hurr durr don't touch anything outside official repos or you will annihilate your system" but if experienced users keep warning about that then it's probably true.

[Rachael]

GZDoom is fairly benign with its package installation (it should not interfere with anything else), and is mostly self-sufficient.

Also - binaries are binaries. Trading an ELF from another system is not much different than transferring an EXE between different versions of Windows.

Thus, the whole "stability risks" thing seems very untrue, to me. You should be just fine.

The only real danger is when a dependency does not exist on the target system - trying to force its presence is where the risks begin.

[Eonfge]

Hey,

Good new everybody. I'm currently in the review stage of publishing GZDoom on Flathub!
https://github.com/flathub/flathub/pull/1155

I was a bit bothered by the fact that there was no easy way to play GZDoom on Fedora Linux, so I got into gear and I took the initiative. There were already GZDoom powered packages for Freedom and Blade of Agony so the process was actually quite easy.

Why Flatpak? Well, it's a cross distribution, decentralized, sandboxed, and atomic packaging format. It's developed by Red Hat and it's getting more and more speed. It is to be expected that within a few years, the whole GNOME Desktop Environment ecosystem will switch to Flatpak. Better for users because they have more security and stability: Packages are sandboxed and one faulty library can't brin down the whole system. For develoeprs, it is nice because of it's cross distro, atomic nature: Build once, and patch every existing client by just sending the delta. No more clients who are running terribly out-of-date editions.

I'm not totally new to Flatpakking, although this is my first forum post here. I'm currently maintaining a more comedic flatpak app called Cowsay, so I feel confident that I'll be able to maintain the GZDoom build for the coming years.

Care to try?

Code: Select all • Expand view

flatpak install --user https://dl.flathub.org/build-repo/7385/org.zdoom.GZDoom.flatpakref

Only available for a few days. Then it's removed.

[Blzut3]

I too find it strange "hurr durr don't touch anything outside official repos or you will annihilate your system" but if experienced users keep warning about that then it's probably true.

I'm late to the thread, but the reason people say that is that there are no protections against the repository providing "updates" to packages provided by your distro. If the package repo updates some core package then you have the potential to do damage or make your system unstable. Generally speaking it's pretty clear if the repo is of this variety, usually the repos people get into trouble with are updates to mesa, GCC, or the kernel. These can easily go wrong if the maintainer of the repo doesn't know what they're doing.

Repos which provide stand alone packages like the DRD Team one are harmless in this regard. Even if a distro were to provide any of the packages I offer, none of them are core system components so will not affect the overalls stability of the system.

The second reason why people mention this is that any of the packages could have arbitrary scripts in them, and these get executed as root. This is purely a trust issue, and personally I don't think you should execute a flatpak or appimage if you don't trust the source either.

However, if you were to pick apart any of the packages on the DRD Team repo (at least the latest versions since I figured out how to do packaging remotely properly) you'll see that they either have no scripts, or the script is just running stuff that the package static analyzer (lintian) says to run which are completely harmless.

The official .deb seems to work OK, but using Ubuntu binaries on Debian is strongly discouraged.

This advice is just pure BS in my book, and just propagates the myth that there's such a thing as a distro specific binary. The only time this is remotely valid is if it's a core system component. For example, don't try to install Ubuntu systemd, mesa, or something like that on Debian. It might work, but you'd be more likely to cause damage.

For games? A Linux binary is a Linux binary. If the ABI matches, it will work. If not, then you can remove the package and it's like it never happened.

As for why I build deb packages instead of flatpak or appimages? Because that's what I personally prefer, and since these packages literally just dump some files onto your file system, and have dependencies minimized to an ABI stable set flatpak and appimage provide literally no benefit. (If anything they're less efficient since you don't get to benefit from fixes to the basic libraries, most notably SDL, that your distro may provide.) Well besides supporting more distros, but I don't particularly care about that myself. Although since the dependencies are minimal, it's actually not hard to extract the debs on any distro you like. Use ar to get the data.tar.xz from the deb (deb is a renamed .ar file) and then extract that. Would I probably recommend using Eonfge's flatpak instead of doing that, sure, but you can if you want. I've done it with something like 7 distros + BSD years back just to prove that a Linux binary is a Linux binary if the developer understands ABIs.

[Graf Zahl]

since you don't get to benefit from fixes to the basic libraries, most notably SDL, that your distro may provide.

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.

[Rachael]

The official .deb seems to work OK, but using Ubuntu binaries on Debian is strongly discouraged.

This advice is just pure BS in my book, and just propagates the myth that there's such a thing as a distro specific binary. The only time this is remotely valid is if it's a core system component. For example, don't try to install Ubuntu systemd, mesa, or something like that on Debian. It might work, but you'd be more likely to cause damage.

For games? A Linux binary is a Linux binary. If the ABI matches, it will work. If not, then you can remove the package and it's like it never happened.

Thank you for this! It always seemed just a bit insane that it was so strongly "discouraged" to run an Ubuntu-compiled binary on, say for example, Linux Mint.

That being said, I pretty much agree with everything you've said.

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.

[Blzut3]

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.

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.

[Graf Zahl]

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.

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.
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.

[dpJudas]

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.

By the way, the Windows Vista application breakage was rarely caused by ABI breakage. It was applying system security rules (such as making C:\Program Files only writable by administrator) that largely only affected applications that did stupid things. That kind of breakage would affect either approach.