On Sun, Jan 13, 2019 at 7:21 PM Keith Packard <keithp@xxxxxxxxxx> wrote: > > Yes:ish. It should not *normally* happen. But you may run into it in > > uncommon situations like e.g. chrome using a statically linked version > > of fontconfig that has a different fontconfig cache format. > > Hrm. I don't get the sense that we've got a solution to this problem > yet. Given that the contents of the flatpak cannot change on the fly, > would it be sufficient to generate a new 'salt' value for the flatpak > each time it is changed? It might be sufficient to use the name of the > flatpak including a version as this salt (that has the advantage of > making the flatpak reproducible, which you probably want to encourage). The plan was to generate a new random salt each build. We *do* in general want to make flatpak builds as reproducible as possible, because the magic of ostree means identical files are deduplicated on disk and not downloaded on updates. However, if fixed set of small files change each build that is not a huge problem. So, in such a setup we're ok as long as the statically linked fontconfig is new enough to respect the salt config. However, we could run into issues if e.g. chrome statically links to an older fontconfig. Such fonconfig versions would ignore the salt, and miss the runtime-shipped caches, instead picking up the host caches. It seems in that case the host cache would have a mismatching mtime though, and we'd generate a new one, plus we'd regenerate the host cache for the remapped dir. So this should work, at some cost in performance. > > Yeah, there will be two files. One static in the runtime > > (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak > > (/run/host/fontconf.xml). > > Sounds like we've got a plan for this part -- fix my mapping code to use > config bits separate from the <dir> elements, then add a 'salt' > mechanism in the config bits that stirs in some random data when > generating the cache keys for specific directory trees. > > Let's figure out how we should handle the stale flatpak fonts cache > issue. Once we've settled that, we can go implement the whole mess and > get a new fontconfig release made in time for debian freeze. Sounds good to me. Actually, i'm planning a flatpak stable (1.2) release in the next few weeks, and I would like to add support for the flatpak-side of this to the release. So, if we can just decide the syntax for the dir remapping bits now I can add support for that. Then we can do the runtime part when there is a fontconfig release that supports it. _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
