[bug#49107] [PATCH core-updates] gnu: fontconfig: Use (locally) deterministic caching

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Sarah Morgensen <iskarian@mgsn.dev> skribis:

> Make fontconfig use directory contents rather than modification time to
> determine cache validity (by pretending that mtime is broken).
>
> * gnu/packages/patches/fontconfig-cache-ignore-mtime.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Register it.
> * gnu/packages/fontutils.scm (fontconfig)[source]: Use it.
> [arguments]: Unset SOURCE_DATE_EPOCH for tests.
> ---
>  gnu/local.mk                                      |  1 +
>  gnu/packages/fontutils.scm                        |  7 ++++++-
>  .../patches/fontconfig-cache-ignore-mtime.patch   | 15 +++++++++++++++
>  3 files changed, 22 insertions(+), 1 deletion(-)
>  create mode 100644 gnu/packages/patches/fontconfig-cache-ignore-mtime.patch
>
> Hello Guix,
>
> This patch attempts to make fontconfig's caching work seamlessly on Guix,
> instead of requiring users to manually run `fc-cache -f` after installing or
> removing fonts. This addresses <https://issues.guix.gnu.org/18640>.
>
> Fontconfig usually uses a directory's mtime as its checksum. However, when
> fontconfig detects a "broken mtime" filesystem, it will generate a directory
> checksum from the directory listing contents. This is slightly slower, as it has
> to stat all the files in all font directories. Unconditionally enabling this
> mode should get us more regular behavior.

Nice, sounds like an improvement!

Does Fontconfig stats all these files every time an application starts?
Did you compare ‘strace -c some app’ with and without this change, to
get an idea of what it costs?

> I am not confident this method is fully deterministic; particular filesystem
> capabilities may still be an implicit imput in the checksums. This should only
> matter when distributing pre-generated caches.
>
> Fontconfig does honor SOURCE_DATE_EPOCH, but without a reliable mtime,
> fontconfig has no way of knowing when to update such a cache. SOURCE_DATE_EPOCH
> is now disabled for the tests because they assume working cache invalidation.

So tests fail is we leave SOURCE_DATE_EPOCH, right?

Thanks for addressing this longstanding issue!  (And apologies for the
delay…  Now’s a good time to get semi-high-level changes like this one
in ‘core-updates’.)

Ludo’.