On Thu, Jan 10, 2019 at 4:29 AM Keith Packard <keithp@xxxxxxxxxx> wrote: > 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. That is correct. > 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. Hm, I see. > 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. Right. > 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. Indeed, that would be able to accomplish both with the minimal efforts for us at least. though they might came up with this but they didn't do it that way. so there might be some reason why they didn't do so. packaging issue perhaps? > 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. I can't figure out completely but, fontconfig may needs to deal with different namespaces in a cache filename to avoid a collision between host and sandboxes. dunno if we may see different state in the future but it might be represented as a depth in a filename to make it different like 0:<md5>-le64.cache-<version> for host and 1:<md5>-le64.cache-<version> for a sandbox. we could increase a depth for a child in sandbox as needed, anyway. We can mix up caches that is located at the same place then. the last missing piece would be to map them to the right place. flatpaks should knows where they mounted directories to. they can create a map table with proper parent depth and current depth I think. I may be missing something so this might not work though... > (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 -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
