ZDoom

Also, just to follow up real quick... I just read through this entire thread and wanted to say thanks to Eonfge for maintaining this flatpak, and for your ambitions to push other id Games source ports to flathub! I, for one, am grateful they're there.

Hey guys, speaking of flatpak... I installed the GZDoom flatpak on my Linux Mint 19.3 system today to tinker around with it and it doesn't work very well. Whenever I run it, it asks for my IWADs. It won't look in the folder that I put into the gzdoom.ini.

It also won't accept any command line parameters, either. For instance:
flatpak run org.zdoom.GZDoom -iwad /home/thebrightside/Games/GZDoom/IWADs/DOOM.wad

It still asks me for my IWADs.

Has anybody been able to get it to work?

The only thing I can manage is to put the IWADs right into ~/.var/app/org.zdoom.GZDoom/.config/gzdoom, but then I can only play vanilla DOOM since no other command line parameters work. :-/

git clone https://github.com/flathub/org.zdoom.GZDoom.git
cd ./org.zdoom.GZDoom/
flatpak-builder build-dir/ org.zdoom.GZDoom.yaml --force-clean
flatpak-builder --repo=repo --force-clean build-dir org.zdoom.GZDoom.yaml
flatpak build-bundle ./repo GZDoom.flatpak org.zdoom.GZDoom

It's worth noting that any of you could also have a maintainer status if you so desire. In that case, even if I catch a bus, you can keep pushing updates. You'll not even need much flatpak knowledge to maintain the current deployment.

It's totally possible of cause to make stand-alone bundles for archive purposes: http://docs.flatpak.org/en/latest/single-file-bundles.html

[b]Shell script that should make a package based on the current master:[/b]
[code]
git clone https://github.com/flathub/org.zdoom.GZDoom.git
cd ./org.zdoom.GZDoom/
flatpak-builder build-dir/ org.zdoom.GZDoom.yaml --force-clean
flatpak-builder --repo=repo --force-clean build-dir org.zdoom.GZDoom.yaml
flatpak build-bundle ./repo GZDoom.flatpak org.zdoom.GZDoom
[/code]

I'm not sure how your back-end works, but it should not be hard to integrate this in an existing build server.

[quote="Blzut3"]Auto updates are the right thing to do most of the time, but occasionally there are ...[/quote]
... incompatibility of save files.
But you can update flatpaks manually. I don't know about other distros but on Arch flatpaks don't update automatically.

Indeed. All I can say is "Why not?"

[quote="Rachael"]If I do something like that, then there needs to be some way to track its usage. If Blzut3 and Graf and mental are all okay with it, the package can be uploaded directly to Github and then the link can appear on the front page.[/quote]
Why not? If it will stop receiving updates at some point, we can always remove its mentions.

[quote="Eonfge"]That's against Flathub policy. Flathub is a Flatpak repository system, which not only hosts but also compiles and updates deltas. They compile everything based on a manifest and they can provide updates to all users worldwide. One thing they do not provide, is single downloadable files. That would introduce many headaches, because how can users get reliably run the latest version? Flatpak combines many systems: It's a repository, it's a sandboxing system, it's an updating system.[/quote]
As I posted earlier there's a way to [url=http://docs.flatpak.org/en/latest/single-file-bundles.html]export the flatpak into a single file[/url] which can be imported offline. In my opinion offline install and the ability to archive old versions is a very important thing for an official binary.

Auto updates are the right thing to do most of the time, but occasionally there are regressions that break mods and there should always be the ability to roll back to the previous version of GZDoom if needed.
[quote="Rachael"]If Blzut3 and Graf and mental are all okay with it ...
However, Flatpak users must understand that updates to the flatpak are purely contingent on an external contributor.[/quote]
This is exactly what I suggested earlier, so you can put me down as OK with it.

No problem. I'll see to it that the package gets updated and unless you together decide differently, we'll keep things how they are right now.

I see. I guess I was confused. I'll discuss this with the other developers then and gather some opinions before making the final decision.

[quote="Rachael"]
If I do something like that, then there needs to be some way to track its usage. [/quote]

Here you're touching on some sensitive topics. Right now, there is no easy way for anybody (even downstream maintainers like me) to see the amount of downloads on Flathub:
https://github.com/flathub/flathub/issues/177

But I can provide you with a total amount of users and installs though:
https://github.com/paulcarroty/flathub-app-stats/releases
https://ahayzen.com/direct/flathub.html

Since it's release 5 days ago, GZDoom had 33 unique downloads (2 would be mine). Give it some time and lets see how the numbers evolve.

[quote="Rachael"]
If Blzut3 and Graf and mental are all okay with it, the package can be uploaded directly to Github and then the link can appear on the front page.[/quote]

That's against Flathub policy. Flathub is a Flatpak repository system, which not only hosts but also compiles and updates deltas. They compile everything based on a manifest and they can provide updates to all users worldwide. One thing they do not provide, is single downloadable files. That would introduce many headaches, because how can users get reliably run the latest version? Flatpak combines many systems: It's a repository, it's a sandboxing system, it's an updating system.

Your manifest and build info is here:
https://github.com/flathub/org.zdoom.gzdoom
So if you want to compile it yourself, you're free to do so, but that will be without Flathub integration.

[quote="Rachael"]However, Flatpak users must understand that updates to the flatpak are purely contingent on an external contributor.[/quote]
If you want, I have no problem adding an extra disclaimer stating that this is an unofficial downstream package.

[quote="Rachael"]That means it's going to be a lot slower than actual releases.[/quote]
I will try to always provide the latest updates, but I cannot guarantee that. One benefit will be, is that my updates can be pushed automatically to users. If I hit publish, it takes 15 minutes before it is live. Compare that with these sources:

https://pkgs.org/download/gzdoom
https://repology.org/project/gzdoom/versions

The fast majority of Linux packages it hopelessly out-of-date because they are not easy to update. Flatpak tries to fix that. Any maintainer can publish any update to all Flatpak users. Flatpak is new though, so it still has some ground to cover before it will be the default for most users.

---

Anyway, that was more text then originally planned. Hope this all makes it more clear to you. Have you already seen GZDoom in the software center?
Image of GZDoom in GNOME Software: https://imgur.com/a/nV1m1QJ

[quote="Eonfge"][b]Edit[/b]
@Rachael, as webmaster you might opt to add a Flathub link. I understand it if you decline, because it does make it a lot more official, but know that there are badges and such available for upstream projects to include:
https://flathub.org/badges[/quote]
If I do something like that, then there needs to be some way to track its usage. If Blzut3 and Graf and mental are all okay with it, the package can be uploaded directly to Github and then the link can appear on the front page.

However, Flatpak users must understand that updates to the flatpak are purely contingent on an external contributor. That means it's going to be a lot slower than actual releases.

[quote="Rachael"]Well - honestly - I am glad someone went and did it. :)[/quote]
That's how it often works.

In all fairness, this was not completely altruistic... I run Fedora, and there were no easy packages available. That triggered my to come into action, and to create a Flatpak that could technically run on every Linux distribution. I've also added Zandronum and I've created a short list of source prots I would like to see included on Flathub:

https://github.com/flathub/flathub/issues/1160
This will keep me occupied for a few months :D

[b]Edit[/b]
@Rachael, as webmaster you might opt to add a Flathub link. I understand it if you decline, because it does make it a lot more official, but know that there are badges and such available for upstream projects to include:
https://flathub.org/badges

[quote="Eonfge"]In other news:
https://flathub.org/apps/details/org.zdoom.GZDoom[/quote]
Well - honestly - I am glad someone went and did it. :)

[quote="Graf Zahl"][quote="Cacodemon345"]Windows also allows a program to load libraries from its own directories, something without we wouldn't be able to run old DDraw games using Wine DLLs.[/quote]

The lack of this is the big issue on Linux. You can do it but it's not the default. Even starting a shell script locally requires prefixing its name with "./".
I think if this hadn't been the case there would be far more software on Linux that'd just ship its binary dependencies along with the main executable, but the setup as-is actively discourages people from doing so.
[/quote]

Getting a bit back on topic, that is what AppImage and Flatpak both try to tackle. You can package your own with it's own set of libraries. So if you must use SDL 2.0.1, then you can add that version without coming into conflict with other packages.

In other news:
https://flathub.org/apps/details/org.zdoom.GZDoom

[quote="Cacodemon345"]Windows also allows a program to load libraries from its own directories, something without we wouldn't be able to run old DDraw games using Wine DLLs.[/quote]

The lack of this is the big issue on Linux. You can do it but it's not the default. Even starting a shell script locally requires prefixing its name with "./".
I think if this hadn't been the case there would be far more software on Linux that'd just ship its binary dependencies along with the main executable, but the setup as-is actively discourages people from doing so.

Regarding the compiler problems, you will find that on all platforms. Languages evolve and sometimes newer compilers will break badly written old code. No magic in the world can protect againd poorly written stuff from two decades ago. Sometimes you are lucky that modern compilers still swallow it (or that the code is still being maintained) but often this isn't the case and it'd just break on more modern platforms, sometimes the source no longer compiles, but often even having a binary won't work because it depends on bad hacks.