Jump to content
The Dark Mod Forums

I've created a manifest for a flatpak package


Ludvig
 Share

Recommended Posts

Hi!

This is a manifest to install the installer as a flatpak. It contains the following:

  • com.thedarkmod.TheDarkMod.yml - Flatpak manifest, easily readable.
  • com.thedarkmod.TheDarkMod.desktop - Desktop file. You can right click on it in an app launcher and choose "Installer" to open the installer program.
  • com.thedarkmod.TheDarkMod.png - Icon for .desktop file, can't use .ico for this.
  • launcher.sh - Simple script to initialize installation directory and choose between installer or game.

On first run the script will copy the installer to a sandboxed location under your user home (~/.var/app/com.thedarkmod.TheDarkMod/data/TheDarkMod), and then start it. The game will then be installed to this location. Afterwards, the script will check for the game launcher instead and run that if possible, otherwise it'll try to run the installer again. You can also open the installer by right-clicking on the icon and choosing "Installer", or manually by running:

flatpak run com.thedarkmod.TheDarkMod install

For the people using prime/optimus systems it should also default to running on the dedicated GPU rather than the internal when using the desktop-file.

 

To test this app locally you need to install flatpak-builder and the org.freedesktop.Sdk runtime in flatpak. You can then build and install the package by extracting the zip, entering the tdm directory in a terminal and running:

flatpak-builder --force-clean --user --install build com.thedarkmod.TheDarkMod.yml

 

To get this app published on flathub you can submit it via the instructions at https://github.com/flathub/flathub/wiki/App-Submission. I've never submitted an app myself so I don't know exactly how it's done, but AFAICT, it should just be putting these 4 files in a git repo and send a pull request to the flathub repo on github.

 

Feel free to edit any files as you see fit. The app name was based on the webpage URL, but maybe you want to change that or edit the capitalization or something like that. :)

 

 

 

thedarkmod-main-2022-05-06.zip

Edited by Ludvig
Updated zip
  • Like 4
Link to comment
Share on other sites

Nice! Welcome to the community, and good work.

  • Like 1

{ 0 | 🞵 } = funk_tastic

My missions:           Stand-alone                                                      Duncan Lynch series                              

                                      Down and Out on Newford Road              the Factory Heist

                                                                                                  A House Call

                              

Link to comment
Share on other sites

Welcome to forums!
Thanks for sharing this!

The main problem with having more ways to install/build TDM is maintaining all of them, and making sure players don't get into more problems. That's why we keep away from having official TDM packages in Linux distributions and similar stuff.

Is there any benefit in this flatpak approach, compared to running tdm_installer manually?

P.S. You should not specify checksum for tdm_installer.linux64.zip, because this file is regularly updated, and each update changes the checksum.

Link to comment
Share on other sites

To make it more known to the public.
The community got also tdm packages in repos, like Opensuse and maybe the freebsd port.
But a bit out of date. 

Welcome and thanks for creating the flatpak, Ludvig.
If you build the flatpak just around the tdm installer, like what you did, you are set.
Maybe following some pointers from our wiki page, to avoid some user problems.
(Like the write permissions, but your flatpack installs into a writeble folder, but only for one user not all)
(see wiki articles: Installation and Installer and Manual Installation)
 

But it will be also nice if someone would create a fully standalone package and ship it to popular repos.

Edited by freyk

Info: My portfolio and darkmod graphical installer
Amnesty for Bikerdude!

Link to comment
Share on other sites

3 hours ago, stgatilov said:

Welcome to forums!
Thanks for sharing this!

The main problem with having more ways to install/build TDM is maintaining all of them, and making sure players don't get into more problems. That's why we keep away from having official TDM packages in Linux distributions and similar stuff.

Is there any benefit in this flatpak approach, compared to running tdm_installer manually?

P.S. You should not specify checksum for tdm_installer.linux64.zip, because this file is regularly updated, and each update changes the checksum.

Thanks!

Yes, that's a fair point. However this uses the official installer instead, both for the original installation and updating. So once this is submitted, it should maintain itself (the minecraft and steam packages work in a similar way AFAICT). This would be basically just an easy way of distributing the official installer to people through flathub.com.

There are some benefits, in my opinion:

  • Reliability: Applications in flatpak uses runtimes instead of the system libraries. This takes up more space, but you as a packager know exactly what system your program runs on. It only needs to match a single runtime environment, rather than several possible configurations that can vary between distributions. Users won't need to go hunting with ldd if the program doesn't run anymore, if it works on one computer it should work on all.
  • Security: Flatpaks are sandboxed by default. This game, when ran through flatpak, can't access any of the users regular files, which might help convince users to give it a try!
  • Visibility: it'll show up in every linux users store if they use flatpak and have the flathub repository enabled: https://flathub.org/apps/category/Game
  • Control: The control over the package would be in the hand of the developer instead of the distro packager. So in this case, you'll still have full control in how the game is packaged and distributed, since it uses the same installer and you'd be the ones with access to the flatpak manifest on flathub.
  • Maintenance: Compared to regular distro packages, this won't have particularly high demands to stay up to date. This is the manifest file:
app-id: com.thedarkmod.TheDarkMod
runtime: org.freedesktop.Platform
runtime-version: '21.08'
sdk: org.freedesktop.Sdk
command: launcher.sh
finish-args:
  - --share=ipc
  - --socket=x11
#  - --socket=fallback-x11
  - --socket=wayland
  - --device=dri
  - --socket=pulseaudio
  - --share=network
  - --talk-name=org.freedesktop.Notifications

modules:
  - name: thedarkmod
    buildsystem: simple
    build-commands:
      - install -Dm755 tdm_installer.linux64 /app/bin/tdm_installer.linux64
      - install -Dm755 launcher.sh /app/bin/launcher.sh
      - install -Dm644 com.thedarkmod.TheDarkMod.desktop /app/share/applications/com.thedarkmod.TheDarkMod.desktop
      - install -Dm644 com.thedarkmod.TheDarkMod.png /app/share/icons/hicolor/48x48/apps/com.thedarkmod.TheDarkMod.png
    sources:
      - type: archive
        url: https://update.thedarkmod.com/zipsync/tdm_installer.linux64.zip
        sha256: f321c07177393834e37e9821f532994e6a871179c2875fa46460a6fdf7054884
        
      - type: file
        path: launcher.sh
        
      - type: file
        path: com.thedarkmod.TheDarkMod.desktop

      - type: file
        path: com.thedarkmod.TheDarkMod.png

It's a fairly simple structure, I think. Basically what would be needed is to change the sha256-sum when you want to push an update. Runtime-version can also be updated, the runtime environment is updated once a year. Flatpak is able to have several runtimes installed though so there's no rush in updating that, and it's just a matter of changing the version number to the new version after making sure the game runs with the new runtime as well. Updating the runtime shouldn't have any other issues compared to distributions updating their system packages normally, but worst case you can keep using an older runtime if needed and it shouldn't impact the rest of the system.

(Speaking of the sha256 sum, it's needed by the flatpak builder, but it'll be baked into the package once it's on flathub so it shouldn't matter. It'll auto-update itself on the first run regardless, since the current version doesn't match the checksum either way due to the builder stripping the files when packaging. The initial installer is only used as a way to kickstart the actual installer, it copies the packaged installer, runs it, lets it auto update and then it'll use the one provided through the auto-updater afterwards).

Now, there's only really two drawbacks with this system as I see it:

  • Flatpaks needs runtimes, this means that if this is the only flatpak you use you'll need to install the freedesktop runtime which is an added 100-200MB or so. However, runtimes are shared between packages, so if any other package in the system also uses the freedesktop runtime, it'll already be installed.
  • Installing desktop shortcuts and stuff, I don't think it'll work. Even if you give it write-access to the user desktop, the shortcut itself would probably need to be modified. In fact, I don't think you can customize at all where the game will be installed the way it's currently set up, it'll always end up in the package directory under ~/.var, like (most) flatpak packages.
  • Like 1
Link to comment
Share on other sites

Posted (edited)
2 hours ago, freyk said:

But there ARE tdm packages in repos, like opensuse. But a bit out of date. 

Welcome and thanks for creating the flatpak, Ludvig.
If you build the flatpak just around the tdm installer, like what you did, you are set.
Maybe follow some pointers from our wiki page, to avoid some user problems.
(see wiki articles: Installation and Installer and Manual Installation)

But it will be also nice if someone would create a fully standalone package and ship it to popular repos.

Thanks!

Yeah my first thought was to compile it from source and create a standalone flatpak package. The downside there would be that, in flatpak, I'm not sure how it would handle installations of user missions for example. The game seems to assume the install location will be writable from what I can tell, which is why I needed to copy the installer to the users own data dir to make everything work. I think this is also a problem with traditional packages regardless, judging from the manual installation part there, and I don't think this is "fixable" in a good way unless the game is severely modified (install to a read-only location and put missions in ~/.local/share/tdm and configs in ~/.config/tdm for example), but I'm not an expert at this.

However, that could also be done with the flatpaks, if it was implemented in that way. You could then make the manifest  automatically fetch the source from the svn repository, either specifying a certain commit/tag/release or from the most recent one, install the build dependencies and build the package, and then put it on flathub for testing. The user would then just install the package as usual, no compilation time and no build environment necessary, and no need to use the installer. The flathub build bot could also run this nightly and use the flathub beta repository for people who want to test nightly builds, essentially providing both a stable package and a nightly one for testing. It's way above my level to make that work nicely though. :)

Edited by Ludvig
word choice
Link to comment
Share on other sites

The problem of dependencies is quite severe on Linux.
We minimize it by linking almost everything statically, except for OpenGL and glibc. I'd be happy to link glibc statically too, but it does not work 😀 So instead I simply build official binaries on a pretty old Linux distro.
Flatpak solves the glibc problem at least.

Speaking of checksum. If you absolutely need one, you can bundle tdm_installer archive with the manifest. Then checksum will not change. And the installer should self-update to the latest version anyway on the first run.
That's how @freyk does it in his installers.

As a user, I'd be happy to forbid programs access to anything outside their directory, but I doubt they will work properly after that 😀 I hope TDM does not break from this restriction: in my opinion, it should never go outside installation directory (unless the user tweaks some filesystem cvars that should not be changed).

Additional 100-200 MB is not a problem at all for a 3GB+ game.


I think I should try to install flatpak and install TDM via it myself.

I must admit I don't want to maintain anything like this myself. However, this manifest basically wraps our official installation instructions, seems to require almost no maintenance, and allows to publish TDM on a well-known distribution system without legal burden (like on Steam).

  • Like 3
Link to comment
Share on other sites

Posted (edited)
1 hour ago, stgatilov said:

The problem of dependencies is quite severe on Linux.
We minimize it by linking almost everything statically, except for OpenGL and glibc. I'd be happy to link glibc statically too, but it does not work 😀 So instead I simply build official binaries on a pretty old Linux distro.
Flatpak solves the glibc problem at least.

Speaking of checksum. If you absolutely need one, you can bundle tdm_installer archive with the manifest. Then checksum will not change. And the installer should self-update to the latest version anyway on the first run.
That's how @freyk does it in his installers.

As a user, I'd be happy to forbid programs access to anything outside their directory, but I doubt they will work properly after that 😀 I hope TDM does not break from this restriction: in my opinion, it should never go outside installation directory (unless the user tweaks some filesystem cvars that should not be changed).

Additional 100-200 MB is not a problem at all for a 3GB+ game.


I think I should try to install flatpak and install TDM via it myself.

I must admit I don't want to maintain anything like this myself. However, this manifest basically wraps our official installation instructions, seems to require almost no maintenance, and allows to publish TDM on a well-known distribution system without legal burden (like on Steam).

Yeah that's true, the installer could very well be bundled with the manifest! I just did it the way I'm most used to, fetch the sources from upstream and use local files only when absolutely necessary. Either way though, once it's on flathub it shouldn't really matter since it'll use the installer from when the package was built, it won't fetch it during the package installation itself. And, as you say, after the user launches the app the first time, the installer would then update itself regardless. :)

And yeah, flatpak solves both the glibc and the opengl problem. The freedesktop runtime provides the needed opengl libs, which won't suddenly change regardless of what else the user runs on their system. If they use ubuntu from 2018 or arch linux, either way the runtime will provide the same environment. As a bonus, the way flatpak handles glibc, this should also enable the game to run on platforms that use other libc implementations (such as musl) if I understand it correctly, but I haven't tested that myself.

As far as I can tell from my testing, everything seems to work. I can change settings, download and install missions, and play the game on either graphics card on my optimus laptop. So the game seems already very well behaved for sandboxing (I was honestly surprised how easy it was to get it to work). If it needs other permissions later we can add that in the manifest, but so far there doesn't seem to be any reason to. :D

Edited by Ludvig
  • Like 1
Link to comment
Share on other sites

I have stopped on adding flathub repo (Ubuntu 16.04):

user@ubuntu:~$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: Unacceptable TLS certificate

Obviously, many people have the same issue, but simple solutions like reinstalling ca-certificates or similar do not work.
Also, I can download the file at this URL using wget without any problem.
It looks like something that flatpak uses for HTTPS is messed up.

Link to comment
Share on other sites

Posted (edited)
3 hours ago, stgatilov said:

I have stopped on adding flathub repo (Ubuntu 16.04):

user@ubuntu:~$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: Unacceptable TLS certificate

Obviously, many people have the same issue, but simple solutions like reinstalling ca-certificates or similar do not work.
Also, I can download the file at this URL using wget without any problem.
It looks like something that flatpak uses for HTTPS is messed up.

I got the same error running from the live environment, but after doing an install in a VM, enabling universe, multiverse, xenial-backports, doing a system update and then adding the alexlarsson PPA to install flatpak it seems to work. Maybe something is out of date?

Skärmbild från 2022-04-16 11-02-06.png

Skärmbild från 2022-04-16 11-02-27.png

Skärmbild från 2022-04-16 11-02-51.png

EDIT: For what it's worth, it worked immediately on 18.04. I'm guessing you're probably using 16.04 to build for maximum compatibility of glibc, which is good, but in 18.04 I didn't have to add the PPA to get flatpak installed, everything worked straight from the live environment. Since 16.04 is on extended maintenance (meaning, people would need a support contract to keep receiving security updates I think), I don't think many people will be running the game on such an old platform. But it should be possible to use the flatpak too, if they choose to. :)

Edited by Ludvig
Link to comment
Share on other sites

Ok, I ran TDM within flatpak, and I get terrible noise instead of sound with "[ALSOFT] (EE) available update failed: Broken pipe" spam. It sounds like the game fills the sound buffers only a few times per second, so I hear 3-5 brief pieces of sound samples per second.

That's what I see when spam starts:

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'ALSA Default' [ACTIVE]
OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC2/ADC (CARD=AudioPCI,DEV=0)'
OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC1 (CARD=AudioPCI,DEV=1)'
OpenAL: device 'ALSA Default' opened successfully
OpenAL: HRTF is available
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
[ALSOFT] (EE) available update failed: Broken pipe

When I start native TDM binary, it works fine, but prints exactly the same log as posted above.
So I suppose lack of real-time priority is not critical.

I can only speculate that VM uses some custom sound settings, but flatpak does not catch them.
All sounds in-game lag by almost half a second. Also sounds in Firefox play immediately.

Link to comment
Share on other sites

1 hour ago, stgatilov said:

Somehow it has helped.

With this installation, can you load savegames properly?
The word "darkmod" occurs twice in the path, which is known to cause problems.

 

Yep! Tested it during the training missions with two different saves. Maybe it's a windows-specific problem? Paths in linux are case-sensitive which might also make a difference? I'm not actually a programmer so my knowledge is very limited in of the specifics in how it actually works on a deeper level.

Worst case we could rename it to something like com.tdm.TDM, but that might be hard to decipher for people unfamiliar with the game? Plus it's usually a nice thing if parts of the name references the actual source (like freedesktop.org being the owner of org.freedesktop-packages).

Link to comment
Share on other sites

Posted (edited)
47 minutes ago, stgatilov said:

Ok, I ran TDM within flatpak, and I get terrible noise instead of sound with "[ALSOFT] (EE) available update failed: Broken pipe" spam. It sounds like the game fills the sound buffers only a few times per second, so I hear 3-5 brief pieces of sound samples per second.

That's what I see when spam starts:

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'ALSA Default' [ACTIVE]
OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC2/ADC (CARD=AudioPCI,DEV=0)'
OpenAL: found device 'Ensoniq AudioPCI, ES1371 DAC1 (CARD=AudioPCI,DEV=1)'
OpenAL: device 'ALSA Default' opened successfully
OpenAL: HRTF is available
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
[ALSOFT] (EE) available update failed: Broken pipe

When I start native TDM binary, it works fine, but prints exactly the same log as posted above.
So I suppose lack of real-time priority is not critical.

I can only speculate that VM uses some custom sound settings, but flatpak does not catch them.
All sounds in-game lag by almost half a second. Also sounds in Firefox play immediately.

Odd, yeah. These are the corresponding lines when running the flatpak on my native linux system:

----- Initializing OpenAL -----
Setup OpenAL device and context
OpenAL: found device 'ALSA Default' [ACTIVE]
OpenAL: found device 'HDA Intel PCH, ALC294 Analog (CARD=PCH,DEV=0)'
OpenAL: found device 'HDA Intel PCH, HDMI 0 (CARD=PCH,DEV=3)'
OpenAL: found device 'HDA Intel PCH, HDMI 1 (CARD=PCH,DEV=7)'
OpenAL: found device 'HDA Intel PCH, HDMI 2 (CARD=PCH,DEV=8)'
OpenAL: found device 'HDA Intel PCH, HDMI 3 (CARD=PCH,DEV=9)'
OpenAL: found device 'HDA Intel PCH, HDMI 4 (CARD=PCH,DEV=10)'
OpenAL: device 'ALSA Default' opened successfully
OpenAL: HRTF is available
[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.21.1
OpenAL: found EFX extension
OpenAL: HRTF is enabled (reason: 1 = ALC_HRTF_ENABLED_SOFT)
OpenAL: found 256 hardware voices
----- Initializing OpenGL -----

I don't see any other openal stuff after that. Given how old 16.04 is in terms of software, it could just be some complication between openal, flatpak and the VM software, I think.

Actually, looking through the terminal feedback, on your last post you mentioned it looking for the "darkmod" path. Seems it still is:

no 'darkmod' directory in exe path /home/ludvig/.var/app/com.thedarkmod.TheDarkMod/data/TheDarkMod, skipping
WARNING: using hardcoded default base path

I guess that because it doesn't do partial matches it seems to work. We could probably change the install directory to just "darkmod" (full path would be ~/.var/app/com.thedarkmod.TheDarkMod/data/darkmod then instead), and it should still work as expected. On the other hand, I don't know if it actually matters, since it seems to be working either way right now?:)

EDIT: Actually, I changed the path in the launcher script to install to a directory named "darkmod" instead, and everything still seems to work fine. I think it's probably better to use that then, since it's what the game seems to expect! The path warning disappeared too, so that'll make less risk of misleading warning messages I guess.

Edited by Ludvig
  • Like 1
Link to comment
Share on other sites

I played a bit inside flatpak.

First of all, the sound issue goes away after 30 seconds of playing.
I guess it is some kind of race condition...

I checked that settings are saved properly, games are saved/loaded, missions are downloaded.
I think everything works.


I did a few changes to the manifest:

1) Changed URL to https://update.thedarkmod.com/zipsync/tdm_installer_fixed110.linux64.zip --- that is fixed version of installer that will be the same in the future. Some sort of compromise between changing sha256 every time and adding tdm_installer binary to the manifest archive.

2) Added semicolon to two lines of .desktop file, because flatpak builder (or maybe something else) prints warnings about them (I suppose these properties are lists, and lists are semicolon-separated and -terminated):

Categories=Game;
Actions=Installer;

Also, I see warning about PrefersNonDefaultGPU property: it says that the property must start with X- because it is not a standard one. I think my OS is too old, and the property was added recently, so there is nothing to do about it.


tdm_installer marks installation path as red because it contains dot characters.
Don't remember why dots were not whitelisted (it installs fine)... maybe to avoid confusion between files and directories.
Is it possible to avoid ".var" subdirectory, and what is $XDG_DATA_HOME ?
I don't like that many gigabytes are stored in a directory which is hidden by all file browsers.

Yes, renaming last directory from TheDarkMod to darkmod is a good idea.
And the bug that I referenced probably triggers only when two directory components are equal to "darkmod".

Link to comment
Share on other sites

44 minutes ago, stgatilov said:

I played a bit inside flatpak.

First of all, the sound issue goes away after 30 seconds of playing.
I guess it is some kind of race condition...

I checked that settings are saved properly, games are saved/loaded, missions are downloaded.
I think everything works.


I did a few changes to the manifest:

1) Changed URL to https://update.thedarkmod.com/zipsync/tdm_installer_fixed110.linux64.zip --- that is fixed version of installer that will be the same in the future. Some sort of compromise between changing sha256 every time and adding tdm_installer binary to the manifest archive.

2) Added semicolon to two lines of .desktop file, because flatpak builder (or maybe something else) prints warnings about them (I suppose these properties are lists, and lists are semicolon-separated and -terminated):

Categories=Game;
Actions=Installer;

Also, I see warning about PrefersNonDefaultGPU property: it says that the property must start with X- because it is not a standard one. I think my OS is too old, and the property was added recently, so there is nothing to do about it.


tdm_installer marks installation path as red because it contains dot characters.
Don't remember why dots were not whitelisted (it installs fine)... maybe to avoid confusion between files and directories.
Is it possible to avoid ".var" subdirectory, and what is $XDG_DATA_HOME ?
I don't like that many gigabytes are stored in a directory which is hidden by all file browsers.

Yes, renaming last directory from TheDarkMod to darkmod is a good idea.
And the bug that I referenced probably triggers only when two directory components are equal to "darkmod".

Good that the sound issue goes away by itself, I haven't really tested this in a VM so I don't know any other potential issues. I don't think many users would be playing this in a linux VM either way, but it's good to check for compatibility regardless.

1) Yeah, that's probably the best compromise.

2) Yeah that seems to be correct. PrefersNonDefaultGPU is indeed a newer thing in the .desktop files, the old one was X-KDE-RunOnDiscreteGpu=true which newer versions of flatpak-builder complains about if you include them. :D

.var is the standard to store user data for flatpaks. I could change the launcher to install in the users home dir instead, but then we'd need permissions for the entire home dir which would sort of defeat the sandboxing (and is usually discouraged by flatpak users AFAIK). Other games in flatpak also seem to prefer the .var directory, probably for the same reason of sandboxing (steam, minecraft, various emulators etc all store their things in .var).

$XDG_DATA_HOME is just a standard name for the user local data, which normally would be /home/username/.local/share, but in flatpak will mean /home/<username>/.var/app/<appname>/data, it's the sandboxed user data storage basically. This is where apps "should" store their application data, while configs usually would go in XDG_CONFIG_HOME (which means ~/.config normally or ~/.var/app/<appname>/config in the flatpak sandbox).

I have made a github just to keep track of the changes, if you want you can put a pull request there: https://github.com/ludvigng/thedarkmod otherwise I'll just make the changes from your suggestions in the thread either way. :)

Link to comment
Share on other sites

I've updated the link in the OP with the latest version from the git repo of the launcher script and flatpak manifest etc. I've also checked the script with shellcheck to ensure it passes shell sanity, and it detected no issues. Only suggestions were to properly escape the variables and to add || exit to the cd command in case it fails, both which have been added.

thedarkmod-main-2022-05-06.zip

Link to comment
Share on other sites

Ok, thanks!
I'm afraid I can't work on TDM for uncertain amount of time (week or weeks)...

Speaking about putting this to flatpak repo.
I won't be surprised if they accept only the manifests which build stuff from source code.
At least, I heard that's the policy of Linux distributions.

Link to comment
Share on other sites

16 minutes ago, stgatilov said:

Ok, thanks!
I'm afraid I can't work on TDM for uncertain amount of time (week or weeks)...

Speaking about putting this to flatpak repo.
I won't be surprised if they accept only the manifests which build stuff from source code.
At least, I heard that's the policy of Linux distributions.

For flathub it depends, I think. Usually it's good hygiene, but sometimes it's not possible due to licensing or other issues. I'm not sure if flathub has a hard stance on it, compared to debian or fedora. If we submit it, they'll might comment on it and it could depend on the reply. Zotero for example does something similar to our manifest, where it downloads the official binary package from their web page and then just puts the files in the correct location, even though it's technically mostly AGPL? https://github.com/flathub/org.zotero.Zotero/blob/master/org.zotero.Zotero.json

If that becomes an issue, I could try whipping up a manifest that builds from a particular rev from the svn, but I'm not familiar with svn in general and it would likely take much more time for me to test and build it, so it'd have to happen after the summer (I'm working on my master's thesis now, then I have some work lined up). I'm also not sure how to work in the downloadable missions with that, since technically they would have to be installed in the installation dir, which in this case would not be writeable by the game itself. So either it'd have to copy the compiled code to the user dir in .var and then run from there, basically duplicating the amount of disk space, or we'd have to modify the game code (and I'm not a programmer! :D).

So I think that could be reason enough to motivate why we do it the way we do it. It'd either be a big waste of space, or it'd be skirting the line of the security model if we modify the app install dir during runtime or we'd have to do considerable work to change the code. Neither option is good, compared to what we're doing now.

Link to comment
Share on other sites

  • 1 month later...

Returned to this story.

Looking at flathub requirements:

Quote

Accessing the network is not allowed during the build process, to download extra files, everything that an app requires must be included within the manifest. There is a community provided set of tools to make this easier for some projects (such as npm) that would traditionally want to access the network.

It means running tdm_installer is explicitly forbidden.

Link to comment
Share on other sites

1 hour ago, stgatilov said:

Returned to this story.

Looking at flathub requirements:

It means running tdm_installer is explicitly forbidden.

The tdm_installer is not run during the build process, it's run only when the user first launches the app. This is more concerning stuff that uses npm or similar package systems that might want to download other packages during the build. Any such dependencies must be declared in the manifest itself and downloaded by the flatpak builder instead.

The build process for this package is just downloading the tdm_installer along with the launcher script and desktop file, and placing these files in a specified location. Nothing is actually built or run during the build. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recent Status Updates

    • duzenko

      Please, can we finally group the missions by year in the game menu?
      · 3 replies
    • duzenko

      I vaguely recall someone recently complained about two-sided materials (curtains?) not getting lighting from both sides
      I just found a piece of code that's supposed to do just that
      Where was that discussed? (@nbohr1more?)
      · 8 replies
    • Xolvix

      I still play classic Doom (albeit with user-made mods and maps rather than the original campaign) on a regular basis. A game from the early 90's which has still got a healthy following in 2022. Pretty amazing.
      · 3 replies
    • Nort

      I'm beginning to understand why people who aren't into social clubbing "don't last long" on this project, and why it's so full of holes. When moderators are siding with bullies, by closing down threads that they derail, then I start to wonder if I should support the platform to begin with.
      I'm sure that the core development is solid, but when you're constantly tone policed and bullied, and moderators are playing into it too, then the project will just drive away talent, and replace it with socialites instead. ...and without talent, you only end up with a small skeleton crew trying to do everything themselves.
      ...so Dragofer and Airship Ballet, and all you other socialites, you win. From now on I'll just keep to myself. You'll never be able to do my work, but at least you'll be happy together, and that's what matters to you.
       
      Update
      Actually, I have to revise my statement:
      I actually messaged greebo - the top dog, I gather - about nbohr1more's outburst of insanity below, and since I haven't even heard back from him, I just have to assume that there's not a single core programmer here, who's not backing nbohr's threats. ...and that's bad.
      ...so if you're a newbie reading this, or an honest soul like ZergRush, then just slowly back out of these forums, run, and don't look back. This is nothing more than a cult posing as a game development project, using Thief and IDTech4 to sucker hopefuls in, to do work for them, while trying to cajole them into something going on behind the scenes, which apparently - according to nbohr - is something that should be hidden from the state. These people aren't programmers - they don't even understand things like how to fix the simplest bugs. All they have, is an engine, and an IP, and some sort of fascist social cult. There was some other project I saw being made in the Unreal Engine. Try joining that project. ...or start a project of your own. Anything but this asylum.
      Hopefully that was "divisive" enough for a final post, because at this point I really want people to leave this place. This project is, on a management level, just awful garbage, run by garbage people, apparently from the top down, and I'm just glad that they have a garbage place to stay, together, and hopefully forever.
      Nort
      · 9 replies
    • The Black Arrow  »  Araneidae

      A spidey! I love spideys 🕷️
      · 0 replies
×
×
  • Create New...