Bug 57749 - ttfonts %postun, %triggerin suggestions
Summary: ttfonts %postun, %triggerin suggestions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ttfonts   
(Show other bugs)
Version: 7.3
Hardware: noarch Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-20 19:34 UTC by Rex Dieter
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-07 15:28:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Rex Dieter 2001-12-20 19:34:44 UTC
In the case where a user (say, like me (-: ) installs other rpms 
containing truetype fonts that happen to install to the same location as 
ttfonts does, the ttfonts package upon removal does the following 
undesirable things:
1.  removes /usr/share/fonts/default/TrueType from xfs's fontpath
2.  leaves behind fonts.scale and fonts.dir files that contain stale data.

Also, an enhancement suggestion:
3.  use xftcache when appropriate.

In order to complish this, I suggest modifying ttfonts %postun script as 
follows... For shorthand, I'll use a macro 
%define ttfontdir /usr/share/fonts/default/TrueType
cd %{ttfontdir}
if [ "x$(find . -name "*.ttf" 2>/dev/null)" != "x" ]; then
  # stuff left-over, reconfig
  ttmkfdir >fonts.scale 2>/dev/null     ||:
  mkfontdir             2>/dev/null     ||:
  xftcache %{ttfontdir} 2>/dev/null     ||:
 # we're empty
 rm -f encodings.dir XftCache
 chkfontpath -q -r %{ttfontdir}         ||:

# trigger for xftcache in case XFree>=4.1.0 is installed after we are
%triggerin -- XFree86 >= 4.1.0
xftcache %{ttfontdir} ||:

Comment 1 Ngo Than 2002-01-07 13:19:13 UTC
It's fixed in ttfonts-1.0-5. You will find it in next rawhide release.

Comment 2 Rex Dieter 2002-01-15 18:46:16 UTC
We've got a buglet left over from this change.  I now get an error when I:
rpm -e ttfonts
Error: can't change to /usr/share/fonts/default/TrueType

To avoid this problem, we can try postponing the cd until after it is verified 
that ttfontdir is not empty:
if [ "$1" = "0" ]; then
  if [ "x$(find %{ttfontdir} -name "*.ttf" 2>/dev/null)" != "x" ]; then
  # stuff left-over, reconfig
    cd %{ttfontdir}
    ttmkfdir >fonts.scale 2>/dev/null ||:
    mkfontdir             2>/dev/null ||:
    xftcache %{ttfontdir} 2>/dev/null ||:
    # we're empty
    rm -f %{ttfontdir}/encodings.dir
    chkfontpath -q -r %{ttfontdir} ||:

(I also removed the rm -f XftCache since it is now owned by this package per 
bug #58129)

Comment 3 Bernhard Rosenkraenzer 2002-02-12 17:22:30 UTC
 Fixed in 1.0-9

Comment 4 Rex Dieter 2002-11-07 15:28:40 UTC
%trigger XFree86  
fails for rh8 since xftcache is no longer included (in favor of Xft2's  
fc-cache).  Perhaps it would be best to either remove the trigger altogether  
*or* change the trigger to first try to run/use fc-cache then xftcache if the  
former is not available.  
On a slightly different, but related issue, perhaps all this  
font-postprocessing should be included in some external font helper  
application, something akin to type1inst, but for ttf fonts, then all you'd  
need to put in %post would be:  
(or whatever you'd want to call it).  That way, all ttf font packages could  
share a single, unified post-processor... and you'd not have to rebuild every  
ttf font package when/if you ever want/need to modify %post.  

Comment 5 Rex Dieter 2002-11-07 16:10:31 UTC
It just occurred to me that the ttfonts package doesn't actually exist anymore  
in rh8... and that the existing ttfonts-* packages don't have the trigger 
anyway.  Nevermind... (-:

Note You need to log in before you can comment on or make changes to this bug.