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

[Alexander Larsson]

Ugh, forgot to CC the list...

On Mon, Nov 5, 2018 at 11:06 AM Nicolas Mailhot
<nicolas.mailhot at gmail.com> wrote:
>
> I really don’t see why all this requires adding third party files to
> font directories (which will break other software). The container tech,
> not fontconfig, decides what it wants to reuse from the host. The
> container tech, not fontconfig knows it exposed all the host font
> directories or just some of them. The container tech, not fontconfig,
> knows how it remapped directories. The container tech, not fontconfig,
> knows it exposes a cache format that may be incompatible with the
> container fontconfig version.

It is true that the container system decides what to forward to the
container. But I don't think it is a good idea that each container
system should know about the internal behavior of every library that
could ever run in a container. That is just not scalable, nor will it
work if some new library suddenly appears and now all container
systems needs to generate its config format. Fontconfig is what picks
the identifier to use for its cache, and a uuid is a better identifier
than a pathname for reasons I've explained.

But anyway, it is not only about containers. As I said, the same
situation appears e.g. if you boot into a different OS or image with a
shared home partition or when using a shared NFS homedir on multiple
machines.

And what is 3rd party about the uuid file? It is added by fontconfig,
because it is used by fontconfig. And how does this file break other
software?

> So the container tech is creating a situation where host files can not
> be reused as-is, and it needs to tell fontconfig all this, instead of
> trying to pretend this is business as usual and hope nothing will break.
>
> ie provide fontconfig a map file that says "you can use the additional
> cache file located here if its format is compatible with the container
> fontconfig version. When using this additional cache, only take into
> account those file paths and map them to container paths this way"

That is one way to fix the issue, but it requires changes both in
fontconfig as well any possible code anywhere that uses kernel
namespacing APIs. I don't really see why that solution is better and
that fontconfig generating its own cache identifier is somehow evil?
In fact, it seems fragile and complex with an failure mode where
fontconfig silently returns broken results due to using stale caches.
That does not sound like good engineering to me.

> You can't seriously suggest adding UUID files to every host directory
> you remapped and that matter somewhere, just to avoid telling apps you
> remapped things in the first place. Because if you actually think this
> would be a good idea, the whole thing belongs in the container
> filesystem namespace, not in per-app kludges. If you want to do that add
> a "get dir uuid" syscall there and then ask apps to use it.

This is a strawman. I never suggested adding UUID files everywhere.
Why would I do that? It is not necessary, because nothing but
fontconfig relies on pathnames like this.