Mailinglist Archive: opensuse-packaging (104 mails)

< Previous Next >
Re: [opensuse-packaging] Packaging Godot
[Full quote to let the list gain from Rémi's insights]

Rémi Verschelde:
@cunix: I'm not subscribed to the openSUSE packaging ML, so I'll let
you forward my answer if it doesn't pass through moderation.

Regarding unbundling fonts, I advise not to bother with it for the
following reasons:

- The main reason for unbundling fonts in distros is so that all
packages can share the same fonts instead of bundling their own, thus
reducing the install size on disk by avoiding duplication of data.
There's no security risk, so it's much lower priority than unbundling
libraries (especially as disk space is cheap).

- One could argue that it allows to use the latest and greatest
version of the fonts as packaged on the system instead of the one
upstream bundles, but that also implies that we're using a version of
the font that upstream did not test - unless the downstream packagers
are very experienced with the software they're packaging, it could
lead to some issues if the system font is not compatible with the
application for whatever reason.

In Godot's case more specifically:

- Godot is designed to be self-contained and portable, so it doesn't
rely on anything being installed on the system (apart from the most
common system libraries). When packaging for a Linux distro, this is
usually not what we want, so we can unbundle more libraries and fonts
if needed and hardcore paths to the latter in the binary. It loses its
portability but nobody is meant to take /usr/games/godot or
/usr/bin/godot to send it to their friends. That said, it means that
fonts are compiled into the binary by the buildsystem, so to unbundle
them, you have to disable that and also add code to load system fonts
(potentially adding a new dependency on fontconfig to Do It Right™).
That's non negligible work, for a low priority policy IMO as mentioned
above.

- A more compelling reason for *not* unbundling fonts is that, unless
you also build all export templates for all platforms (Linux
(portable!), macOS, Windows, Android, iOS, HTML5, UWP) with the exact
same fonts and provide those to openSUSE users, users of your package
would have a different font when testing their game in the
openSUSE-packaged editor and when shipping their games with the
upstream-provided export templates. And that would be quite bad for
the user experience. The same rationale applies to any kind of
downstream patching of the editor that would introduce incompatibility
with upstream-provided export templates. It *can* be done, but then
you'd have to build and package all export templates too, which
requires cross-compiling toolchains for the above-mentioned platforms
and several hours of build for all those binaries.

- Finally, Godot's fonts are hand-picked to ensure that we have all
the symbols we want, especially the now-deprecated
DroidSansFallback.ttf and DroidSansJapanese.ttf, which Google stopped
distributing, but which is the best we could find to cover most Asian
and Arabic symbols with a reasonably sized font (3.6 MB and 1.1 MB
respectively).

Thank you so much for this comprehensive explanation Rémi!

You convinced me to leave the provided fonts untouched and i hope this
will be acceptable for Factory.

2018-08-29 1:18 GMT+02:00 cunix <cunix@xxxxxxx>:
Ludwig Nussel:
[...]
Anyways, as you can see in modules/openssl/stream_peer_openssl.cpp
there even is a commented call to SSL_CTX_load_verify_locations()
"for testing". Pretty close. Replace that with a call to
SSL_CTX_set_default_verify_paths(), reduce the built in bundle to
not contain any certs at all and you are done. godot will then rely on
openssl to read the system wide cert store.
[...]
Well, explaion the issue upstream and ask them to help with the actual
code :-)

Thank you again very much for holding my hand Ludwig!

After some experiments i implemented your suggestion in one patch and
added a second one to wrap a build option around it [1].
The bundled certs are removed in the spec file.
Does this reflect your ideas?

At least after local compiling that seems to work but we have to test an
obs version more in depth.

Because there might be consequences from this patch I'm not aware of or
certificates might be in use in other parts of Godot that aren't covered
by this solution, i don't feel really comfortable taking full
responsibility for it.
Rémi, do you want to comment? Please ;)

The certificates bundle is mainly used for the Asset Library, to
connect to https://godotengine.org/asset-library,
so if that works with [1], that seems good to me.

I tried to connect to the Asset Library from within a patched Godot
after deleting the bundled certificates during build, once with a build
where "system certificates" was enabled (a) and once disabled (b).

The system was configured to only trust the "DST Root CA X3" root CA for
the "Let's Encrypt" intermediate CA.

(a) showed content, (b) didn't.

Before merging it upstream, we'll likely want to make sure that it
works reliably on all distros, and also on other platforms.

Hopefully that can be tested automatically in some way? Access to other
platforms i don't have.

For the reference, Godot's certs bundle is also derived from the
Mozilla certs data like most distros ship. But it's indeed synced
manually so it can get outdated and require a rebuild against a new
version, so an option to use the system one would be nice to have.

Yes.
In my opinion a major reason for openSUSE preferring to have this option
is, that this will reflect the configuration of a user's system
dynamically and isn't limited to the default trust settings of neither
Mozilla nor the (openSUSE) Distribution.

Whether this will survive the switch to mbedtls and if this is something
upstream might be interested in, I'm not sure but future will tell.

Should be quite similar for mbedTLS. For upstream reviews, it would be
better to start with a patch against the master branch (thus mbedTLS),
and only then another one for the 3.0 branch (OpenSSL) once the former
is approved.

I might look into this because we would have to do it for version 3.1
anyhow but don't want to promise anything right now.
If Godot is accepted for Factory the incentive will probably increase ;)

[...]

[1] The two diffs @
https://build.opensuse.org/package/show/home:cunix:branches:games:tools/godot

cunix

Librement,

Rémi

Thank you again for this detailed help!

cunix 

--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >