sezero / quakespasm

QuakeSpasm -- A modern, cross-platform Quake game engine based on FitzQuake.
https://sourceforge.net/projects/quakespasm/
GNU General Public License v2.0
244 stars 97 forks source link

Flatpak distribution #86

Closed fpiesche closed 11 months ago

fpiesche commented 11 months ago

Hello again!

You may remember me from making a similar request for your Hexen II source port - I'm again running into trouble getting Quakespasm to run on my Steam Deck, specifically because the Deck's operating system does not ship with libopusfile installed which the binary Quakespasm builds require.

As mentioned in the HoT request, adding system libraries to SteamOS is a major pain in the neck - specifically as it's an immutable distro with a read-only root partition; this can be overridden but system updates will wipe any changes to system packages. And as with Hammer of Thyrion, for this reason I've put together a Flatpak build for Quakespasm which will run out of the box on the Deck and any other Flatpak-enabled Linux system and is easy to keep up to date as Flathub will take care of building updated versions including dependencies and the end-user Flatpak installation will transparently check for updated versions on a regular basis.

The build I've put together is a mostly default Quakespasm build with the exception of building SDL2 instead of 1.2 (as this is the default SDL runtime for Flatpak) and enabling FLAC, Opus and XMP (which I could easily switch to Mikmod if you'd prefer this) for maximum audio support.

As with Hammer of Thyrion, I'll be happy to take care of maintenance of these builds and reproducing any issues users report with the Flatpak builds; and as with HoT Flathub's submission requirements need me to ask for permission from you to distribute Quakespasm this way - is this okay with you?

sezero commented 11 months ago

Hello again!

Hey!

does not ship with libopusfile installed which the binary Quakespasm builds require.

QS does not require libopusfile by default though.

I've put together a Flatpak build for Quakespasm [...] The build I've put together is a mostly default Quakespasm build with the exception of building SDL2 instead of 1.2

That's good

[...] and XMP (which I could easily switch to Mikmod if you'd prefer this)

No, libxmp is good and should be preferred over libmikmod

As with Hammer of Thyrion, I'll be happy to take care of maintenance of these builds and reproducing any issues users report with the Flatpak builds; and as with HoT Flathub's submission requirements need me to ask for permission from you to distribute Quakespasm this way - is this okay with you?

Yes. Thanks!

fpiesche commented 11 months ago

QS does not require libopusfile by default though.

Oh, I may be getting things confused with Quakespasm-spiked which does. I couldn't get the regular QS binary builds running without package modifications for some reason... libmad perhaps (which also isn't installed on SteamOS by default)?

PR submitted to Flathub, as seen above :)

sezero commented 11 months ago

without package modifications for some reason... libmad perhaps (which also isn't installed on SteamOS by default)?

Don't know. However, if you want mp3 support you can use mpg123 (libmpg123) instead of libmad by adding MP3LIB=mpg123 to your make command line.

PR submitted to Flathub, as seen above :)

OK. Is there anything that needs adding at QS side?

fpiesche commented 11 months ago

Flathub have requested the appstream metadata be stored upstream; however with QS that's going to be a little more complicated than with Hammer of Thyrion as QS is still quite regularly getting new releases and the metadata includes a mandatory <releases> element.

~I'll put together a GitHub workflow that'll run when a new release is created which'll update the .xml file with the tag version and a link to the release changelog page and then updates the tag to that commit - for a start I'll just create a PR for the appdata.xml file with the workflow to follow if that's okay?~

Just realised that that's a minor issue because it'd result in a drift between the Sourceforge and Github versions of the repo. I'll check whether the releases element is actually necessary in terms of upkeep or if its contents are optional...

sezero commented 11 months ago

I guess this can be closed after #87