Request for a base snap for Godot


#1

After discussing the peculiarities of Godot with @zyga 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)

godot-runtime: 
  base: godot-bare
  contains libc, GL, pulse, etc

godot:
  base: godot-bare
  shares libc, GL, pulse, etc with godot-runtime 
  contains the Godot editor and export templates

<exported game>:
  base: godot-bare
  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.

Make sense?


#2

CC @jdstrand ^

This is the design we discussed during the sprint. I think this is the way we should support godot based games.


#3

why isn’t godot-runtime the base?


#4

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.


#5

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, who was there with you, to see if that’s the case.


#6

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.


#7

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).


#8

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:

name: godot-runtime
base: godot-bare
plugs:
  godot-runtime-1804:
    interface: content
    content: godot-runtime-1804
...

(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)