Summary: | Support fontconfig caches in /var | ||
---|---|---|---|
Product: | fontconfig | Reporter: | Owen Taylor <otaylor> |
Component: | library | Assignee: | Keith Packard <keithp> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | high | ||
Version: | 2.1 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 86455 |
Description
Owen Taylor
2003-01-16 08:49:39 UTC
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 error code. 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.