Went to remove x3270 terminal prog which apparently had fonts -- so they were
removed as well (or at least it was trying to remove them), w/message:
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `touch /usr/share/fonts/Adobe (afm) fonts/fonts.scale
/usr/share/fonts/Adobe (afm) fonts/fonts.dir > /dev/null 2>&1'
---
Meanwhile -- tried to start gvim as root to look at a root-owned config -- but
gvim hung as well -- noted cpu% usage now at 220% (100%=1cpu pegged).  Looks
like it was hung out to dry as well for a 12-minute rebuild of font cache by
font-config.

I went to remove another SW package, xbanner, -- and had it hang as well:
> spm -e xbanner 
warning: waiting for transaction lock on /var/lib/rpm/.rpm.lock

---
Brilliant!  I guess the x3270 package locked the rpm-db before it started
regenerating the font-cache -- so updating rpm's is *also* locked out for the
next 12+ minutes.  

So because I removed a tty prog -- it had to have fonts packaged with it (not
very common, in-my-experience), which locks root out from editing files (or
whatever else it might do/gvim)  AND prevents me from doing any rpm package
maintenance (deinstalling an unused package in this case).

I'm hoping -- or guessing that I might regain control, though not sure -- as I
currently see gvim and fc-cache running @ 100% cpu each in top...

Why isn't fc-cache updated outside of critical paths including running many
X-programs and holding the rpm-db lock?


Fonts seem fairly basic -- and they seem to affect divers systems, so filing
this against BaseSystem -- feel free to change to better location, but it's
amazing how ... a simple removing of a term prog can affect so many [sub]
systems.