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.
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
Not all new directories is in /usr/share/fonts/fonts.cache-1
All new directories is in /usr/share/fonts/fonts.cache-1
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
fc-cache --force-one-level /usr/share/fonts
would force scanning of /usr/share/fonts, but trust modtime
Created attachment 107211 [details]
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]
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
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
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
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