On Mon, Nov 5, 2018 at 12:31 PM Akira TAGOH <akira@xxxxxxxxx> wrote:
>
> On Mon, Nov 5, 2018 at 6:18 PM Alexander Larsson
> <alexander.larsson@xxxxxxxxx> wrote:
> > I don't see why we can't just fix the empty-directory regenerating
> > uuid case instead?
>
> Because people doesn't want to see creating a file under
> /usr/share/fonts say on host. that's the most concerns/complaints I've
> ever seen and this way may looks negative approach like returning to
> the old behavior where we had created cache files under /usr in the
> past I guess.
>
> Hmm, I totally missed the point that flatpaks can have own fonts in
> the container under /usr/share/fonts where the host fonts is installed
> and could be different. indded mapping font directories may not help
> in this case.
>
> For another idea that satisfies not creating a file under /usr, can
> flatpak rebuild symlinks at the startup time?
> That is to represent mapping between UUID (or the unique value if it
> doesn't like) and dir to a symlink.
>
> The directory structure looks like at host:
> /path/to/fontconfig/caches/on/host/
> \___<unique value>-le64.cache-7
> /path/to/fontconfig/dirs/on/host/:
> \___<unique value>.dir -> /usr/share/fonts/foo
So, lemme be more concrete here. On the host, we have fonts in
/usr/share/fonts/foo, and say we generate a unique id of XYZ for it
the first time it is used. We'd then end up with something like:
/usr/share/fonts/foo/foo.tft
/var/cache/fontconfig/XYZ-le-64.cache-7
/var/cache/fontconfig-dirs/XYZ.dir -> /usr/share/fonts/foo
When next time fontconfig looks for caches for /usr/share/fonts/foo it
would read all the symlinks in /var/cache/fontconfig-dirs and find the
real one (or create a new one).
The advantage here is that the uuid file is outside of /usr, but on
the other hand lookup of it is a bit slow.
In flatpak, we could handle this by having some background process
that monitored /var/cache/fontconfig-dirs and mirrored it, but
rewriting the paths. And then we could mount that in the sandbox
instead of the real one. Not an ideal setup really, it seems like it
makes both the host and the sandbox setup slower and more complex, for
very little gain. It also becomes complicated when we have fontdirs in
the sandbox, because those would *also* need to have a fonconfig-dirs
dir full of symlinks, so now we would have two directories we would
have to scan for these.
A better solution would be to use a *global* unique id as part of the
cache lookup. For example, say we have a file /etc/fonts/cache-id. And
to generate a cache ID for a directory, we use
md5("/usr/share/fonts/foo" + read("/etc/fonts/cache-id")). Flatpak
could then create its own cache-id file for each app. And fedora
silverblue could generate a different cache-id for each compose, so
that caches were not aliased between versions. In fact, in addition to
the cache id we could also add in /etc/machine-id, which would let us
fix the shared NFS homedir case. This would fix the aliasing of
/usr/share/fonts between different containers, but not the lookup for
/run/host/fonts, so it would have to be combined with something like
keiths dir key, where you can configure the /run/host/fonts dir to use
a custom cache-id file.
Of course, this is a lot of complexity and moving parts to avoid a
file in /usr. I still don't quite understand such a file is such a big
deal. (I mean, other than the clear bug of constantly regenerating
it.)
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
