[Fontconfig] Patch: fix for fc-cache with relative path

[Patrick Lam]

Frederic Crozat wrote:
> Hi,
> 
> the new cache location code has introduced new bugs in fontconfig :
> -when using fc-cache . in a directory, the string used to generate
> md5sum key is always "./fonts.cache-2" which will collide if the same
> command is run in several directories.
> -a similar problem happen when using : fc-cache /foo/bar and
> fc-cache /foo/bar/ : strings used to generate md5sum are not the same,
> resulting in different cache.
> 
> The attached patch fixes the issue.

I've committed my patch.

> I've also found other problems but I haven't fixed them (help welcome) :
> -if you have a directory containing fonts.cache-2 file which are not
> up-to-date but cache in /var/cache is up to date, running fc-cache will
> not remove those fonts.cache-2, even with fc-cache -f. I tried to force
> removal of old cache when using -f but doing so would break multiarch
> cache (for instance, we run fc-cache -f when upgrading fontconfig
> package, to be sure cache is coherent after a fontconfig upgrade).

Yeah, I'm not sure what the correct solution to that problem is.  I'll
have to think about it.

> -in some directories containing only ttf fonts, running fc-cache -v
> again and again always regenerate the cache (which is strange, since the
> directory was not modified at all).
> -this last bug is causing huge delays when starting applications for the
> first time after running fc-cache as root, since cache is detected as
> dirty and fontconfig regenerates it for the user (and on my test system,
> I have two big chinese fonts of 20MB  and 16MB ...).

Do you have any more hints on when these problems occur?

pat