Flathub/Flatpak package?

[Newbytee]

I think that for easy cross-distribution distribution on Linux having this packaged on Flathub would be nice. This could also potentially give this some extra publicity.

What's a potential blocker is that Flatpak packages mainly are GUI-oriented, so implementing some sort of launcher would be ideal to have done before this.

[Try]

Hi, @Newbytee !

I'm not sure about this Flathub-thing, since I'm not a Linux user. Mark this ticket as help-need to collect opinions.

Generally, first-thing first: Probably *.deb package and binary-releases goes first...

[Newbytee]

I'm not sure about this Flathub-thing, since I'm not a Linux user. Mark this ticket as help-need to collect opinions.

I might take this on myself. My main concern is really that as previously mentioned Flatpak packages tend to be focused on GUI rather than CLI, and as such users might be confused if they install OpenGothic from Flathub and don't see any .desktop entry (like, icon) in their application launcher. One workaround for this could be to e.g. write a shell script that launches in a terminal and asks the user for a path to their installation and then launches OpenGothic.

Generally, first-thing first: Probably *.deb package and binary-releases goes first...

Understandable, but I also think this might be better in terms of reach. Flatpak packages (which Flathub is a repository for) work on any Linux distribution (provided they provide support for Flatpak themselves, which all big ones do)

[Newbytee]

If I make a Flatpak package, what would you want the app ID to be? Usually you'd do the domain name in reverse followed by the name of the program, so in this case it could be com.github.OpenGothic. As you can see there's quite a lot of packages that use com.github as "domain": https://github.com/flathub?q=com.github&type=&language=&sort=

Either way, I thought I'd ask you before I actually go through with that name. Do you have a different domain I should use, or is that fine?

[Try]

com.github.OpenGothic

Yes, this name is OK to me

[DragonSWDev]

@Newbytee

com.github.OpenGothic

Examples you posted also include GitHub user name in ID so shouldn't it be something like com.github.Try.OpenGothic?

[Newbytee]

@Newbytee

com.github.OpenGothic

Examples you posted also include GitHub user name in ID so shouldn't it be something like com.github.Try.OpenGothic?

Yeah, I realised that after writing but didn't update my comment since Try already had replied. I agree that this would be better as otherwise it sounds like it's made by GitHub themselves.

[DragonSWDev]

Good to know. It would be nice to have OpenGothic available on Flathub.

[Newbytee]

One part of publishing to Flathub is having an OARS rating. I'm not super familiar with Gothic (I would like to make my first playthrough via OpenGothic when it becomes more or less fully playable), so it would be appreciated if someone could fill this in for me: https://hughsie.github.io/oars/generate.html

[Newbytee]

Also, is there any way to donate to this? You can add a donation link as part of the Appstream manifest (which is used when publishing to e.g. Flathub).

[Newbytee]

In addition to that, what licence do you prefer the the metadata file to have?

(See: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license)

[Try]

In addition to that, what licence do you prefer the the metadata file to have?

I think MIT, same as license in github is a good chooise

[Nindaleth]

Hey @Newbytee, I've given the OARS thing a try:

<content_rating type="oars-1.1">
  <content_attribute id="violence-realistic">intense</content_attribute>
  <content_attribute id="violence-bloodshed">mild</content_attribute>
  <content_attribute id="violence-desecration">intense</content_attribute>
  <content_attribute id="violence-slavery">moderate</content_attribute>
  <content_attribute id="drugs-alcohol">moderate</content_attribute>
  <content_attribute id="drugs-narcotics">moderate</content_attribute>
  <content_attribute id="drugs-tobacco">moderate</content_attribute>
  <content_attribute id="sex-nudity">mild</content_attribute>
  <content_attribute id="sex-themes">intense</content_attribute>
  <content_attribute id="language-profanity">intense</content_attribute>
  <content_attribute id="language-humor">moderate</content_attribute>
  <content_attribute id="language-discrimination">intense</content_attribute>
</content_rating>

There are some edge cases where I was unsure of how to interpret it within the game and just picked the "worse" option to be on the safe side (violence-slavery, language-discrimination).

[Newbytee]

Pull request sent to Flathub: https://github.com/flathub/flathub/pull/2313

[Newbytee]

Also, @Try, would you like to be added as maintainer/developer in the Flathub repository once it's created?

[Newbytee]

Another question: Apparently Flathub prefers metadata to be licenced CC0-1.0 over MIT. It's not strictly necessary, but they prefer that. Personally I don't really care and I think it would make sense to keep it MIT since the rest of the codebase is MIT, but I thought I'd hear your opinion.

See https://github.com/flathub/flathub/wiki/App-Requirements#appstream and https://github.com/flathub/flathub/pull/2313#discussion_r626526510

[Try]

keep it MIT since the rest of the codebase is MIT, but I thought I'd hear your opinion.

Let's keep it MIT, for now

[Newbytee]

Let's keep it MIT, for now

Sure

Also, about the maintainer/developer thing: I don't expect you to do anything. Rather, I'm asking if you want to have the privileges to do things if you would want to at some point.

[Try]

Rather, I'm asking if you want to have the privileges to do things if you would want to at some point.

Does this flatpack thing require a maintenance? I mean - do we need to upload a new build on every release?

[Newbytee]

Rather, I'm asking if you want to have the privileges to do things if you would want to at some point.

Does this flatpack thing require a maintenance? I mean - do we need to upload a new build on every release?

Yes and no. It used to be that you yourself had to keep the build manifest updated, but now there is something flatpak-external-data-checker which can automatically make a pull request to update the build manifest on new releases and also optionally automatically merge the update if the build succeeds (builds are done on Flathub's builders and correctly linked to their SDK — you don't upload builds yourself). So it can be as automated as you like. However, the way it usually works with Github repositories doesn't seem to work with this one:

https://api.github.com/repos/Try/OpenGothic/releases/latest

As you can see there's nothing here. Compare this to something like Pure Maps:

https://api.github.com/repos/rinigus/pure-maps/releases/latest

And you can see it actually shows the latest release properly. I think it's because you've only made tags and pre-releases, not "normal" releases. There may be another way to do this — I haven't looked very deeply into it — but I'll talk about the Flathub maintainers about it. I have some other things I'd like to resolve first though. But, rest assured, I intend to maintain the Flathub repository.

[Newbytee]

Oh, hold on: https://github.com/flathub/flatpak-external-data-checker#git-checker

There's a tag checker. Should work perfectly for this, provided you stick to the current tagging pattern. It can always be updated though should you want to adopt a new type of versioning.

[PolyMeilex]

Just here to voice my opinion on the subject, I think that flatpack is as important as .deb if not more, because it will run on every distro without the need to go through the packaging and upstreaming process for every distro. (and let's be honest, it will probably never make its way to upstream repos of every distro if any)

For me, it took around 2/3 days to get my project accepted in flathub repos, and the process is smooth in general, after you are accepted you can do whatever without any external review from flathub team, usually it's just bumping the commit hash or tag that will be used to build and release new version from.

Flatpack is steadily growing in popularity and becoming a standard packaging format on Linux (the last standing bastion is Ubuntu with their universally disliked competing snap format).

Packaging as flatpack also allows running open gothic on steam deck easily, as it's the only packaging format it supports out of the box.

[Newbytee]

I was working on a Flatpak for OpenGothic, but I wanted to do it "properly" with sandboxing and got stuck on integrating the glib main loop into the codebase. I do plan to pick it up again, but I'm not sure when that will be. Maybe it would make more sense to publish OpenGothic without sandboxing (or any sort of GUI launcher) in the meantime.

[PolyMeilex]

Sandboxing is a problem for a launcher, not the engine itself, and the launcher does not exist, so I guess it would be fine to release without sandboxing. Or require users to put/link gothic files in a predetermined directory that would be declared in a Flatpak manifest. So instead of exposing all the user's files, we would just expose one OpenGothic directory, but I'm not sure how much value that gives us in comparison to just exposing the whole home directory.

[Newbytee]

My idea was to just show a file picker dialogue with a title saying something like "Select the Gothic game directory" when the user clicks on the desktop icon, and after they do the game would launch. I guess this could be a separate wrapper program? Maybe that would be easier to implement?

[Newbytee]

Hi people! I've picked this back up and I now have a working setup where the OpenGothic Flatpak uses desktop portals to access the game files through a GUI file picker and OpenGothic can be started from a desktop icon, which means you don't have to go through the terminal to launch it. This also does not require any modifications to the OpenGothic source code (which is good, as otherwise OpenGothic itself needs to depend on glib, dbus, and other things just for this small feature) as I am instead using a wrapper program that setups the portal and feeds the provided path to OpenGothic. The Flatpak package sources in their current state can be found here: https://github.com/Newbytee/flathub/tree/opengothic-2. Additionally, I changed the app ID from com.github.Try.OpenGothic to io.github.Try.OpenGothic to suit Flathub's recommendations.

At the moment, all that's missing from getting this submitted to Flathub is https://github.com/Try/OpenGothic/issues/241 (Flathub requires apps to have an icon) and a new release to be made as flatpak-builder does not like it when a submodule is mentioned in .gitmodules but there is no gitlink (https://github.com/Try/OpenGothic/pull/330, https://github.com/Try/ZenLib/pull/8).

[pm4rcin]

Did you try to test if the launcher and game works in pure Wayland?

[Newbytee]

I just assumed it didn't. Let me test.

[Newbytee]

OpenGothic segfaults if you deny access to the X11 socket and allow access to the Wayland one instead. However, the "launcher" can actually use Wayland if the portal implementation supports it as it runs on the host (it's just a GTK/Qt/whatever filepicker, depending on your implementation). It doesn't need the Wayland socket enabled. Implementing Wayland support in OpenGothic could be a future improvement to enhance containerisation, but I don't think it's necessary for the initial submission.

[Newbytee]

I discovered an issue. Attempting to save the game causes it to crash. I'm guessing that OpenGothic is trying to save to some path that Flatpak has marked as readonly or something along those lines. I'll try to look into it.

[Calinou]

I discovered an issue. Attempting to save the game causes it to crash. I'm guessing that OpenGothic is trying to save to some path that Flatpak has marked as readonly or something along those lines. I'll try to look into it.

The Mac Source Ports entry for Gothic 2 lists this, which may be related:

KNOWN ISSUE: When saving a game and typing in a name for the save, the text you are entering may not be visible. Hitting Return should save the game anyway and your title will appear next time you want to load.