bug#26877: building fonts: fontcache must be updated regulary

bug#26877: building fonts: fontcache must be updated regulary

[ng0]

The problem: Right now after just installing fonts, they do
not become available. This can lead to some applications
appearing "broken", etc. Other operating systems solve this
by having a post-install hook which roughly does just this.

A possible solution:
Our fictional, not yet existing, font-build-system should
run "fc-cache --force --really-force", or we should have
a service which does the same for the fonts installed in
the user profile.
At this point a font-build-system would be good anyway,
as the number of fonts keeps growing, and most fonts are
using similar patterns to be installed.
-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

bug#26877: building fonts: fontcache must be updated regulary

[Mark H Weaver]

ng0 <ng0@pragmatique.xyz> writes:

> The problem: Right now after just installing fonts, they do
> not become available. This can lead to some applications
> appearing "broken", etc. Other operating systems solve this
> by having a post-install hook which roughly does just this.
>
> A possible solution:
> Our fictional, not yet existing, font-build-system should
> run "fc-cache --force --really-force",

This cannot work, because the build system code is run within the build
container, where it won't have access to anything in your home
directory.  Furthermore, for most users, the packages are built on
another machine, namely one of our build farm slaves.

Even the build system did somehow have access to your home directory,
building the package is not the right time to run "fc-cache".  On a
multiuser system, if two users request the same derivation, it is only
built for the first user, and the second user simply uses the one that
the first user built.  The relevant time to run "fc-cache" is when the
font is _installed_ in your user profile.

The usual Guix way to handle things like this is to arrange for the font
cache to be part of the profile, and to create a profile hook that
creates the cache from all of the built packages included within.

       Mark

bug#26877: building fonts: fontcache must be updated regulary

[ng0]

Mark H Weaver transcribed 1.2K bytes:
> ng0 <ng0@pragmatique.xyz> writes:
> 
> > The problem: Right now after just installing fonts, they do
> > not become available. This can lead to some applications
> > appearing "broken", etc. Other operating systems solve this
> > by having a post-install hook which roughly does just this.
> >
> > A possible solution:
> > Our fictional, not yet existing, font-build-system should
> > run "fc-cache --force --really-force",
> 
> This cannot work, because the build system code is run within the build
> container, where it won't have access to anything in your home
> directory.  Furthermore, for most users, the packages are built on
> another machine, namely one of our build farm slaves.
> 
> Even the build system did somehow have access to your home directory,
> building the package is not the right time to run "fc-cache".  On a
> multiuser system, if two users request the same derivation, it is only
> built for the first user, and the second user simply uses the one that
> the first user built.  The relevant time to run "fc-cache" is when the
> font is _installed_ in your user profile.
> 
> The usual Guix way to handle things like this is to arrange for the font
> cache to be part of the profile, and to create a profile hook that
> creates the cache from all of the built packages included within.
> 
>        Mark
> 

Okay, you are right about the build system. Your approach reads
better, I was just looking for a way to start a discussion on
this. Right now it is not-obviously broken, and we need to fix
it at some point.
-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

bug#26877: building fonts: fontcache must be updated regulary

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> The usual Guix way to handle things like this is to arrange for the font
> cache to be part of the profile, and to create a profile hook that
> creates the cache from all of the built packages included within.

The problem is that the cache should be mutable so that one can run
“fc-cache -f” after having dropped files in ~/.local/share/fonts, for
instance.

That said, quite surprisingly, I think I never had to run ‘fc-cache’
except in the situation above.

Ludo’.

bug#26877: building fonts: fontcache must be updated regulary

[Maxim Cournoyer]

Hello,

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> The usual Guix way to handle things like this is to arrange for the font
>> cache to be part of the profile, and to create a profile hook that
>> creates the cache from all of the built packages included within.
>
> The problem is that the cache should be mutable so that one can run
> “fc-cache -f” after having dropped files in ~/.local/share/fonts, for
> instance.
>
> That said, quite surprisingly, I think I never had to run ‘fc-cache’
> except in the situation above.

I've never had to do this in years, although I don't use "loose" fonts
manually installed under ~/.local/share/fonts.

Should we close the issue?  Our fontconfig package now honors fonts
found under XDG_DATA_DIRS, and it seems to just work.

Thanks,

Maxim

bug#26877: building fonts: fontcache must be updated regulary

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> The usual Guix way to handle things like this is to arrange for the font
>>> cache to be part of the profile, and to create a profile hook that
>>> creates the cache from all of the built packages included within.
>>
>> The problem is that the cache should be mutable so that one can run
>> “fc-cache -f” after having dropped files in ~/.local/share/fonts, for
>> instance.
>>
>> That said, quite surprisingly, I think I never had to run ‘fc-cache’
>> except in the situation above.
>
> I've never had to do this in years, although I don't use "loose" fonts
> manually installed under ~/.local/share/fonts.
>
> Should we close the issue?  Our fontconfig package now honors fonts
> found under XDG_DATA_DIRS, and it seems to just work.


Hello, I think we can close this now, since this commit:

commit 6f12880a76a6c91058718d15845f8b9d9b529a5a
Author: Sarah Morgensen <iskarian <at> mgsn.dev>
Date:   Fri Jun 18 17:52:05 2021 -0700

    gnu: fontconfig: Use (locally) deterministic caching
    
    Make fontconfig use directory contents rather than modification time to
    determine cache validity (by pretending that mtime is broken).

There is no need to run 'fc-cache' manually, and applications just need
close/restart to use newly install fonts (also manual run here doesn't
remove the need of restart).

bug#26877: building fonts: fontcache must be updated regulary

[Maxim Cournoyer]

Hello,

宋文武 <iyzsong@envs.net> writes:

[...]

> Hello, I think we can close this now, since this commit:
>
> commit 6f12880a76a6c91058718d15845f8b9d9b529a5a
> Author: Sarah Morgensen <iskarian <at> mgsn.dev>
> Date:   Fri Jun 18 17:52:05 2021 -0700
>
>     gnu: fontconfig: Use (locally) deterministic caching
>     
>     Make fontconfig use directory contents rather than modification time to
>     determine cache validity (by pretending that mtime is broken).
>
> There is no need to run 'fc-cache' manually, and applications just need
> close/restart to use newly install fonts (also manual run here doesn't
> remove the need of restart).

Excellent, I had forgotten about that commit.  Thanks to Sarah for
fixing the issue!

Closing.

-- 
Thanks,
Maxim

bug#26877: Fontcache in system profile not updated

[John Soo]

Hi!

I reported #36013 to add support for kmscon’s fonts and keybinding configuration. I have a mostly working solution. The one problem I have when testing it is that kmscon cannot find a font even though it is installed in the system profile. I think it is caused by the system profile not having the updated font cache when starting the kmscon service. Does that sound like a reasonable explanation, given #26877?

Thank you!

John