After discussing the peculiarities of Godot with @zyga-snapd and @popey we have finally come to the following design. This deprecates the previously discussed design:
godot-bare: An almost entirely empty snap (only contains /bin/sh to work around a bug in snapd)
contains libc, GL, pulse, etc
shares libc, GL, pulse, etc with godot-runtime
contains the Godot editor and export templates
shares libc, GL, pulse, etc with godot-runtime
contains the Godot runtime used to make the game
contains the Game's assets
Why do this? Well: games are not like other pieces of software. Games stay ‘useful’ even if they haven’t been updated in sometimes decades. By having just the one godot-runtime we get all the benefits of snaps without game publishers having to worry about updating their snap(s) when a particular core goes out of service. This also allows the Godot team to control the ABI for Mesa, pulse, etc so decades old games could theoretically still run on the Radeon RX980000+ ultra extreme gaming edition which I’m sure they will be at by then.
CC @jdstrand ^
This is the design we discussed during the sprint. I think this is the way we should support godot based games.
godot-runtime the base?
To reduce the number of bases, and to make the godot-bare base a non-issue with regards to security issues with other snap packagers trying to use a Godot base with potentially security sensitive libraries (when used outside of the confines of a game).
By leaving the base empty we ensure that this can’t happen, and the Godot runtime won’t be accidentally used for the wrong purpose.
I’m not sure I follow that. What’s to stop people using
godot-runtime on top of
godot-base for the same potentially nefarious purposes?
Unless all exported games, as well as godot itself, are all published by the same publisher, there’s a bit of work we need to do to have the content sharing implied by this stacking of godot-runtime work, and I’m not at all sure we can both let people use it, and not let people use it, in the way you might be envisioning.
Perhaps I’m missing something; I’ll ask @zyga-snapd, who was there with you, to see if that’s the case.
I don’t think it’s so much about nefarious as about accidental. Using godot-runtime requires a bit of mucking about with LD_LIBRARY_PATH and some Mesa environment variables. It’s not possible to use it and think you’re using some kind of long term supported base (like core).
For the exported games, the expectation is that the
meta/snap.yaml will be generated by the Godot editor automatically. There’s not really an expectation that users will ever interact with snap when using the engine.
In terms of the godot-bare base snap, the requirements are understood and it meets the requirements for a base snap and the publisher has been vetted. I’ve manually approved the base snap (though please see your email for additional details).
As per Godot Engine and Runtime snap naming, the name of this snap is fine, but please at the very least use
content: <thing>-<version of thing>-<distro release/version> where <distro release/version> corresponds to the Linux distribution that the content was built on. Eg, if you built/stage-packages/etc on Ubuntu 18.04, you might use:
(Note: for clarity I specified
content up above, but the value of
content defaults to the name of the plug so it is optional in the above yaml)
@zyga-snapd with the recent fix to
godot just use
bare instead of
godot-bare, assuming we start maintaining the former?
I believe so.
@tmm2k, could you give 2.40 a spin once it goes to stable? I believe you can start to use the bare snap then, or at least let us work together towards making the bare snap useful for godot and the games built using it.
I know I’m coming in late here, but it certainly sounds like your
godot-runtime snap will have many of the same constraints as a base. If the runtime has an evolving API, then you’d want versioned snap names whether it is a base snap or a snap providing content interface slots. Otherwise, you’d need to upgrade all application snaps in lock step with the runtime.
I do realise that there are some roadblocks to shipping a base snap with all of this code in place. I have been experimenting with a base snap that bundles OpenGL libraries, and ran into a few places where the existing AppArmor policies prevented access to some critical files. In many of these cases, updating the policy seems like a reasonable option. My starting point was a PR to update the
opengl interface to allow access to configuration files and drivers for an OpenGL/Vulkan install inside the base snap:
I realise that waiting on changes to be accepted and released in snapd can be time consuming, but it’d be nice if we can get to a point where packaging the runtime as a base snap isn’t so difficult.