It would be nice if /usr is readonly, fontconfig could create
cache files in a different location, maybe in a parallel
heirarchy under /var.
This relates to:
if /usr is read-only, is there a compelling reason why it couldn't include
pre-built cache files? The cache system is designed to handle that gracefully.
If you look at the upstream bug report, you'll see that the
original problem being reported there is that fontconfig
does _not_ handle the situation gracefully.
The fontconfig package does a fc-cache -f on install and
if that can't write a cache file, it exits with a non-zero
I guess one option would be to have fc-cache not consider failure to write the
cache files as an error condition. It's not fatal as fontconfig handles this
condition by creating per-user cache files as needed. Would that suffice? Or
would you really rather risk cache inconsistencies that could easily happen were
the cache file separated from the font directories? In this case, if the cache
files really are up-to-date, then fontconfig will happily them. Now that the
cache files are versioned, the risks of incorrect cache data from an older
version on the server causing problems have been substantially reduced.
Well, the main reason that I suggested the /var approach was that
I recalled you being in favor of it at one point.
I think the approach of quietly not writing cache files in
read-only directories is probably fine. (If it isn't an
error, nothing should be printed out unless you provide
some sort of 'verbose' command line flag.)
Having separate cache files holds a certain appeal, but I fear a certain amount
of chaos if system clocks aren't tightly synchronized or if file systems get
moved around. I'd rather go with the "safe" approach that we currently support,
or (alternatively) build yet another level into the cache system that could
provide a system-wide "global" cache file, much like ~/.fonts.cache-1. That
seems like a lot of work, especially as we consider it likely that people will
be able to pre-build fonts.cache-1 files on the read-only media (or manage them
from the central server).
It appears that access(2) will correctly detect EROFS errors; perhaps fc-cache
should just skip directories for which it has no write permission. That seems
more sensible than building the cache and then not generating an error when
writing that fails.
I've committed a patch to fc-cache that skips unwritable directories. This has
the salutory effect of skipping all of the system-wide font directories when the
user runs fc-cache, while also avoiding problems with read-only file systems.