We can't guarantee that they do however, or that they rerun it when the
fonts get uninstalled.  Does fontconfig cleanly handle a font being
cached but no longer present?

Why do things work fine with FC4 and earlier, but in FC5 there is all
of a sudden a problem with calling fc-cache in xfs initscript?

I'm curious what the real problem here is, and would prefer to see that get
fixed.

I've CC'd Owen for additional thoughts

The real problem is being fixed. 

running fc-cache at boot time won't help anybody who has problems with fonts
being cached but no longer present. Unless you want to force an immediate reboot
after uninstalling a font package...

We've discussed this issue via email, however, for the benefit of other
developers and users who may wonder why this change is being made,
I thought I'd provide a brief rationale here that we can refer people
to for the future.

After the email discussion we've decided to remove the call to fc-cache
from the xfs initscript, as from an xfs package perspective fc-cache is
unrelated to xfs and core fonts, so shouldn't be called from xfs.init.  

It's considered to be a separate issue as to wether or not fc-cache should
be ran by any initscript at boot time or not, however if it is decided that
it should be ran, it should have its own /etc/rc.d/init.d/fontconfig script
perhaps, which is part of the fontconfig package.

The decision for wether that should happen or not is an orthagonal issue
that is beyond the scope of the xfs package however.  That decision is
up to the fontconfig maintainer et al.


I've made the changes and checked them into xfs CVS, however I haven't
built a new package yet as there are other changes I'd like to include
in the package soon.  It'll automatically get into rawhide in the next
build though, so I'm closing it as "RAWHIDE" for now.

Thanks guys.