Red Hat Bugzilla – Bug 140335
Installing fonts packages in fast machine will not update the /usr/share/fonts/fonts.cache-1
Last modified: 2007-11-30 17:07:14 EST
Description of problem: When installing fonts packages in fast machine, even though the %post has fc-cache /usr/share/fonts, it will not update the /usr/share/fonts/fonts.cache-1 properly with new directories and files. How reproducible: everytime Steps to Reproduce: 1. Get ttfonts-indic-1.7-2 2. rpm -e ttfonts-bn ttfonts-gu ttfonts-hi ttfonts-ta ttfonts-pa 3. rpm -Uvh ttfonts-*-1.7-2*.rpm 4. cat /usr/share/fonts/fonts.cache-1 Actual results: Not all new directories is in /usr/share/fonts/fonts.cache-1 Expected results: All new directories is in /usr/share/fonts/fonts.cache-1 Additional info:
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.