On Mon, Nov 5, 2018 at 9:36 PM Alexander Larsson
<alexander.larsson@xxxxxxxxx> wrote:
> 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.
Hmm, I may be missing some point or be wrong but how does this idea be
able to share caches? having different cache id will makes different
md5 and then different cache filename from your explanation. apps
always need to create caches at first time then. this can be done
without implementing this if flatpaks don't share caches and maintain
own cache directory.
Also there are the problem on storing those caches into one directory.
fontconfig will cleans up the unused (invalid) caches at runtime. so
some of them might be picked up by it accidentally.
>
> 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.)
--
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
