New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flatpak Linux binaries #574

Open
TTimo opened this Issue Jan 7, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@TTimo
Copy link
Owner

TTimo commented Jan 7, 2018

look into flatpak to provide Linux binaries

@TTimo TTimo added this to the 1.6.6 milestone Jan 7, 2018

@illwieckz

This comment has been minimized.

Copy link
Contributor

illwieckz commented Jan 8, 2018

Is flatpak able to set q3map2 and other tools available in $PATH too?

I don't know well flatpack, but I remember that appimage (another way to distribute binaries on Linux) can't be a good candidate since it provides access to only one binary by design: the appimage can embed many binaries it can launch itself but they can't be launched from the outside (for example users would be able to run radiant and clicking the build menu will run q3map2, but user would not be able to run q3map2 alone).

So that's something to check: how flatpak handles that case ?

@jdolan

This comment has been minimized.

Copy link
Collaborator

jdolan commented Jan 8, 2018

I think it does support that, because maci went and provided a flatpack build for Quetoo, and we ship quetoo, quemap, quetoo-update, quetoo-master, etc..

https://github.com/maci0/org.quetoo.Quetoo

@magicmyth

This comment has been minimized.

Copy link

magicmyth commented Apr 22, 2018

I've managed to get a working Flatpak manifest going. Repo is:

https://github.com/magicmyth/io.github.TTimo.GtkRadiant

It was a bit of a PITA (no svn in flatpak-builder and dealing with pangox's weird download URL was difficult to figure out) but from my very limited testing it seems to work for me. However, my experience from GtkRadiant is from a very long time ago so I don't know what to really test to stress it. I did make a basic room map and it builds and compiles without issue. The resulting package needs some optimising to remove unneeded bits from the build process but they don't do any harm except for a little extra disc space usage.

All the extra tools (e.g. q3map2) seem to work properly. See the repo's readme for further information on that.

Some notes

I had to patch a couple bits. First I changed the build process from using xml2-config to pkg-config because xml2-config will not function correctly in FDO runtimes (don't really know why but using xml2-config seems to be deprecated). As it is encouraged to use pkg-config over xml2-config these days It might be worth applying my patch to master (see the patches folder of my repo).

The other patch is a quick hack to revert part of commit ba64802. On Linux builds uintptr_t is not being defined so compiling fails there. I'm not really a C++ programmer so I'll let you guys decide what is best to do there but this patch at least gets things going on Linux right now.

Getting it on Flathub

Flathub may have some issues if you wanted to host there for a wider audience access. I had to enable network access for the build phase because the game packs are downloaded over svn during compile (took me a while to figure why that was happening because flatpak does not make it obvious it does this. Grrr). Network access for builds in flatpak is frowned upon and I don't know how Flathub would feel about it. I am quite sure they would require that at the very least the svn checkouts point to specifc commits of the game packages so the builds are repeatable and verifiable. As it is if a game pak was updated it would change the resulting build from past ones.

They might be more accepting if sandboxing was tightened up. Right now for ease of getting going the manifest grants host filesystem access (for the most part) but it could be restricted to the game user config directories like ~/.q3a with persist argument to the directory. Each supported game would need to be added and I have no idea what the other config dirs are called or where they are stored. Note that the user's can manually override such restrictions if they wanted.

@TTimo

This comment has been minimized.

Copy link
Owner Author

TTimo commented Apr 23, 2018

This looks very promising! I only gave gave this a brief look, I'll dig into it deeper soon.

@magicmyth

This comment has been minimized.

Copy link

magicmyth commented Apr 25, 2018

I've been in contact with the Flatpak guys flatpak/flatpak-builder#133 and they are adding support for svn flatpak/flatpak-builder#135. So this will mean the manifest will reference each game pak as a source. I know the grabbing of the paks can be disabled with --no-packs switch. Will the current build system still compile support for the paks if that switch is set but the paks are present in the install/ directory or are some adjustments required?

@TTimo

This comment has been minimized.

Copy link
Owner Author

TTimo commented Apr 25, 2018

There's going to be interesting discussions regarding how flatpak can be used for GtkRadiant and how the integration with the games it supports is done.

The GtkRadiant binary has builtin code to copy game-related content into the games it supports when starting up. That support is always compiled in, --no-packs just disables downloading that content to be part of the zip we release.

I suspect when GtkRadiant is running from a flatpak, it won't be able to copy content into another game's folders (may require some special permissions, may depend if the target game is a host OS install or in a flatpak as well).

A lot of this will have to wait until I get more time to learn and experiment with the tech though. Thanks for doing the early exploration on this.

@magicmyth

This comment has been minimized.

Copy link

magicmyth commented Apr 25, 2018

I don't see why it could not copy things into another game's folder. The filesystem limitations are only what we choose to put on it. And keep in mind user's can override/add to the filesystem with "--filesystem=~/gamefolder"

Thinking out loud, if the game paks are not required at all during build and don't need to actually be their to run ( I know that would be useless if their was none) the game packs can potentially be bundled into flatpak extensions. When installed flatpak would mount the game pak into the GtkRadiant game pak. This way user's can have a smaller download and grab only the game paks they are interested in via their software store.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment