[Fontconfig] [PATCH] Do not remove UUID file when a scanned directory is empty 1 x

Alexander Larsson alexander.larsson at gmail.com
Mon Nov 12 13:39:27 UTC 2018


On Mon, Nov 12, 2018 at 2:22 PM Chris Lamb <chris at chris-lamb.co.uk> wrote:
>
> Dear Alexander et al.,
>
> > There are two issues here:
> >
> > Issue 1)
> > The fonts and caches from the runtime and app are shipped as one unit,
> > so they should always match
> […]
> > Issue 2)
> > The caches from the host appear in a different pathname than when the
> > caches in the cache dir were generated
> […]
> > The global uuid proposal solves issue 1, but as you said, it does not
> > solve issue 2, which is why I ended the mail with the fact that it
> > needs keiths solution also.
>
> Could you also speak to the reproducibility case here? I'm afaid I
> let this thread get slightly ahead of me and — as I previously
> mentioned — I'm a little uncertain of the nitty-gritty font and
> caching minutiæ.
>
> However, I'm very keen to resolve the reproducibility issues so
> please do let me know how I can help.

It depends a bit on what your goal is with reproducibility. My latest
idea is to make uuid file generation optional and manual. This will
make us go back to the previous behaviour of not creating any files
with non-reproducible content in a standard install.

However, suppose you're creating a container image, a flatpak runtime,
or a chroot and you want that to also have access to the host font
directory when it runs. Then you need to run some kind of post-install
script to generate the uuid file in the container image, because we
need an identifier for the font directory itself, rather than its
current content. I.e. if later the files in it changes we want to use
the same identifier when updating the cache for it. This identifier
used to be the pathname, but that doesn't work once you start using
filesystem namespaces to rearrange where directories appear. This
concept of "identifier for location" rather than "identifier for
content" is not really compatible with reproducibility, but if all
you're interested in is "install as host" case then it doesn't matter.


More information about the Fontconfig mailing list