Bug 858842

Sorry for not researching this too well ... this appears to be a duplicate.

*** This bug has been marked as a duplicate of bug 853225 ***

Stefan,  the bug you are reporting is not a duplicate of 853225.

Neither it is a duplicate of related bug 856476.

Besides those two bugs, there are at least 2 other bugs related to
the new font-config system, that I didn't report and are not reported
AFAIK (AsFarAsIKnow)

1) the one you mention where the entire cache is rebuilt with each font installed: pointless.  It should should be done, at MOST, once -- if user is informed of delay and NEEDS the new font immediately after install, OR
should be scheduled for reboot asynchronously after all fonts are installed, in background -- either immediately after all installs are done and system is mostly quiescent (i.e. when system load <.1), OR at night during system maintenance.  (this is the bug you reported).

2) 2nd bug doubling the pain is only on 64-bit systems.  If you have a 64-bit system and have 32-bit font-rendering libraries installed -- as it runs the *same program* in both a 64 and a 32 bit version(fc-cache & fc-cache32 I believe -- though on 32-bit only sys, likely there is only fc-cache == 32bit).  The 32-bit version takes noticeably longer on a 64-bit system.

I may have mentioned both of the above issues, in bug #856476 -- but solving
that bug (don't regen font cache in foreground while user is waiting) doesn't stop both fc-cache versions from running (they shouldn't), nor multiple 
runs of 'fc-cache'.

Note -- this isn't a suse-only problem.  I updated SW on a *windows-Cygwin*.

It tried to do a regen of the fc-cache (or fc-config?) w/each font  AND it also called fc-config, as part of gvim startup -- which took *9 minutes* to run
on a 6-core 3.4GHz, (fc-config is only single threaded -- don't see why as much time is spent reading each file and compiling result), running in 64-bit mode on a 4-way RAID0 using SSD's with 96G system memory.

2nd note... I can think of a 3rd bug, but low priority -- in the fontconfig stuff in that it doesn't detect duplicate fonts and process them only once (i.e. some broken versions of fc-config add symlinks with underscores in the names -- unnecessary for linux (gvim, terminals et al) or Windows), and I, personally, to save space, run a hard-linking dedup util (perl) on my font dir -- bringing 34918 fonts down to 21467 uniq fonts -- which would save ~40% in execution time if it was recognized.  Recognizing _existing_ duplicates (hard
links) takes < 1 minute (usually alot less) on my sys.  Certainly a small amount of time compared to 5 or 10 minutes used by fc-cache[32].

> 1) the one you mention where the entire cache is rebuilt with each font
> installed: pointless.  It should should be done, at MOST, once -- if user is

Correct. This is related to dropping suseconfig.* scripts, see bug 773575 for details.

fontpackages.changes entry says:

-------------------------------------------------------------------
Mon Sep 30 08:44:46 UTC 2013 - pgajdos@suse.com

- run fonts-config only once when installing or upgrading more
  fonts in one transaction
-------------------------------------------------------------------

This change unfortunately haven't hit 13.1, but it should be included in next openSUSE release. Please test in beta versions and let me know how it went.

> 2) 2nd bug doubling the pain is only on 64-bit systems. 

Linda, please stop discussing this in three different bugs. Thanks.

Stefan, thanks for reporting.

(In reply to comment #3)
> > 1) the one you mention where the entire cache is rebuilt with each font
> > installed: pointless.  It should should be done, at MOST, once -- if user is
> 
> Correct. This is related to dropping suseconfig.* scripts, see bug 773575 for
> details.

> > 2) 2nd bug doubling the pain is only on 64-bit systems.  
> Linda, please stop discussing this in three different bugs. Thanks.
---
Please realize the fix you claim is in for 13.2 doesn't fix
issue #2 nor does it address issue/bug #856476.

fc-cache will still be run twice -- for 32&64 bit archs (#2)

fc-cache runs synchronously in foreground as regular user and again as root, taking ~5 minutes each each time the /usr/share/fonts dir is touched (which is often as my font-libs are 3-way synchronized between machines).
(bug856476)


Having been dealt with QA for decades and having been in QA -- bug reporters are always advised NOT to combine bugs unless they absolutely know they are the same root cause --- In this case, you have advised me not to file 3 separate bugs because you don't seem to realize that the other two issues won't be solved by rpm post-install scripts being accumulated into suseconfig-post install scripts.

On top of that -- suseconfig has had this bug in the past when they were rolled in -- If I installed a new font via rpm, I had to wait through a suse config for tex-caching scripts -- which I never used (and have attempted to make sure are not on my system (unless I am specifically using them)).

The bug "fix" you think solves the other 2 issues mentioned, doesn't.  And the fix you think fixes it is itself a problem in the same class as bug856476 -- updating all that stuff in foreground while the user is waiting).

Please don't presume that a user describing 3 or more different problems with a product should roll all the problems into 1 bug.  That's not good QA practice.  all be rolled into 1 bug -- it helps things get lost. 

Example:   if someone presumed that a mitigation fix for this bug (moving the cache runs into 1 run) would also, automatically address #2 (bug #853225),  and bug #856476 (running fc-cache for regular users and root separate -- and making both wait, synchronously when usually not needed), then those bugs might not get addressed or be marked as "low priority"....  ;-)