Bug 140335
| Summary: | Installing fonts packages in fast machine will not update the /usr/share/fonts/fonts.cache-1 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Leon Ho <llch> | ||||||
| Component: | fontconfig | Assignee: | Owen Taylor <otaylor> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4.0 | CC: | eng-i18n-bugs | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | fontconfig-2.2.3-7 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2004-12-06 03:22:00 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 137149 | ||||||||
| Attachments: |
|
||||||||
|
Description
Leon Ho
2004-11-22 13:40:01 UTC
I consider some solution for this: 1. on fontconfig side, though this may be not the best solution, comparing the actual total numbers of directories and nsubdirs() would improves to recognize the changes. 2. if you think it's not a bug, ttfonts-* package maintainer could just do touch -t `date -d '1 second ago' +%Y%m%d%H%M.%S` /usr/share/fonts/fonts.cache-1 and touch -t `date +%Y%m%d%H%M.%S` /usr/share/fonts to avoid this. but I doubt it's the right fix. Not an immediate solution, but one possibility would be to add an option to fc-cache that is like '-f' but only for the toplevel. So, fc-cache --force-one-level /usr/share/fonts would force scanning of /usr/share/fonts, but trust modtime for subdirectories. Created attachment 107211 [details]
proposed patch
Owen, how about this patch? this problem is caused by not updating the parent
fonts.cache-1 at least. even if the modification time is the same between the
directory and the file, fc-cache with this patch can detects the new sub
directory and assumes that fonts.cache-1 is invalid.
Created attachment 107212 [details]
proposed patch
Oops, this is correct one.
Owen, what is your suggestion here? We might randomly hit this bug depends on how fast do users install. Should we patch fontconfig, or to modify all of the ttfonts-* packages? The problem with the patch above is that it only handles the problem for a single level, which works for this particular case, because we have direct subdirs of but leaves many similar problems elsewhere. What I discussed with Keith was making fc-cache call FcDirScan with a special mode where it would ignore timestamps for directories and trust them only for files. You wouldn't want to do that for all uses of FcDirScan (too expensive to do a full tree walk of the filesystem every time an app starts), but doing it for fc-cache is likely OK. Ok, I see. so %post on each ttfonts-* packages needs to be changed after that, right? I think the mode can be the default for 'fc-cache'; I don't think that will be too slow. So no changes to the %post will be necessary. Turned out to be harder to do that fix then I thought. What I ended up doing was a very simple suggestion from Keith Packard ... put a sleep(1) right before the termination of fc-cache. This will make the install 15 or seconds slower, which is definitely unfortunate, but is a very low risk change, which is good at this point. fontconfig-2.2.3-6 has that fix (tested with some artificial cases.) Further tesing appreciated. It works quite okay, and the speed is not bad when install those 5 packages. Now installing between packages there are slight delay (no HDD activities). Waiting for i18n QA to verify this as well before closing. Confirm fixed. Tested with fontconfig-2.2.3-7 and ttfonts-indic-1.8.1 on an average machine and a fast machine, the entries are now updated properly. Thanks. |