Re: Next steps for a reproducible Fontconfig?

"Keith Packard" <[email protected]> Wed, 09 Jan 2019 11:29:05 -0800
Newsgroups	gmane.comp.fonts.fontconfig
Message-ID	<[email protected]>
Akira TAGOH <[email protected]> writes:

> As of the discussion on the list, Keith's changes doesn't address the
> original purpose - allow sharing caches on bind-mounts in flatpaks.
> particularly for the case where flatpaks uses same location in
> sandbox.

I'm probably forgetting a bunch of context here, but I think the problem
was that flatpaks have /run/host/fonts pointing to the "real"
/usr/share/fonts and then a separate /usr/share/fonts of their own with
a small set of fonts, and so you end up with collisions in the cache
file namespace as both directories end up generating the same cache file
name.

> this is the reason why it can't be merged into master.  So just
> reverting the change that removes .uuid file only when a directory has
> empty is done in master so far. if you have .uuid file prior to run
> fc-cache, your issue could be worked around at this moment. for more
> details, you can check what Alex Larsson said on this list.

Making the build reproducible means having all content generated
deterministically based only on the source package and toolchain. The
current UUID files are generated randomly making them
non-deterministic.

For the font cache, making it reproducible requires that the keys
mapping directories to cache filenames be the same each time the cache
is built. This means we cannot use the current randomly generated UUID
values and also have a reproducible system.

I considered whether we might provide a mechanism to generate UUID
values deterministically for purposes of packaging. However, this would
mean that we couldn't use these same packages when creating a flatpak as
the deterministic UUID values would collide if those same packages were
used in the outer system.

Without deterministic UUID values, I'm left with the feeling that
our only available solutions involve changing how flatpaks reference
fonts.

If we agree that a solution to this involves changing the flatpak
mechanism, I'd like to suggest that the most straightforward fix for the
overall system would be to expose the external fonts using the external
path names -- bind mounting the external /usr/share/fonts as
/usr/share/fonts within the flatpak, and creating a new
/usr/share/fonts-minimal (or whatever) to hold the fonts provided by the
flatpak itself. With this change, we can simply delete the UUID code
from fontconfig and go back to using global font paths as keys to the
font cache database.

I'd love to hear about alternative ideas which might lead to solutions
that make builds involving fontconfig reproducible. I'd be happy to take
even vague hints at this point; all I've got at this point are a
collection of dead ends.

(Also, if I've missed or forgotten something relevant, please let me
know; I've re-read a lot of stuff while writing this, but surely
something escaped my notice).

-- 
-keith

_______________________________________________
Fontconfig mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/fontconfig
signature.asc (application/pgp-signature, 832 B)