fontconfig now seems to create caches per-user as needed.
look at the following example:
[EMAIL PROTECTED]:~/.fontconfig$ rm *
[EMAIL PROTECTED]:~/.fontconfig$ su
Password:
silver-cube:/home/thomas/.fontconfig# aptitude reinstall xfonts-75dpi
[snip]
silver-cube:/home/thomas/.fontconfig# exit
[EMAIL PROTECTED]:~/.fontconfig$ xfd -fa Sans
[EMAIL PROTECTED]:~/.fontconfig$ ls -l
total 8
-rw-r--r-- 1 thomas thomas 96 2007-02-02 11:24
1487dd4aecf3164c4a11193169052443-x86-64.cache-2
-rw-r--r-- 1 thomas thomas 96 2007-02-02 11:24
eeebfc908bd29a90773fd860017aada4-x86-64.cache-2
those 2 files have just been created as a local cache. but now look at:
[EMAIL PROTECTED]:~/.fontconfig$ rm *
[EMAIL PROTECTED]:~/.fontconfig$ su
Password:
silver-cube:/home/thomas/.fontconfig# aptitude reinstall xfonts-75dpi
[snip]
silver-cube:/home/thomas/.fontconfig# fc-cache
silver-cube:/home/thomas/.fontconfig# exit
[EMAIL PROTECTED]:~/.fontconfig$ xfd -fa Sans
[EMAIL PROTECTED]:~/.fontconfig$ ls -l
total 0
because now there is a valid cache information in /var/cache/fontconfig
there is no need to create one locally.
so the orginal problem (slow startup) only occurs at the first time
after font installation now (local cache has to be (re)created).
I think xfonts-75dpi not calling fc-cache in postinst is still a bug, as
i see no use in every user having it's own cache (and it's own waiting
time while its created) for system wide installed fonts.
I'd say severity is minor now,for it's more a cosmetic issue not really
affecting usability of the system.
mfg thomas
PS: thanks for reminding me of this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
