Bug 52775

Summary: Ordering of 75/100dpi fonts lost during package updates
Product: [Retired] Red Hat Raw Hide Reporter: Bill Crawford <billc>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-28 23:03:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bill Crawford 2001-08-28 23:03:32 UTC 
Description of Problem:
After upgrading the latest packages, the order of all pairs of fonts (75
and 100 dpi versions) was swapped (I normally put 100dpi first).

Version-Release number of selected component (if applicable):
I upgraded to current Raw Hide version (from the previous Raw Hide), then
upgraded with the packages from
ftp://people.redhat.com/mharris/testing/bleeding-edge/...
I couldn't tell you which version caused the problem, so it may be you've
already fixed this if it's related to the previous font-related bug (the
disappearing font directory entries).

How Reproducible:
Upgrade any/all XFree86 packages containing fonts :oP

Additional Information:
There looks to be a bug in the scripts for the font packages:

postuninstall scriptlet (through /bin/sh):
{
  if [ "$1" = "0" ]; then
    umask 133;/usr/X11R6/bin/mkfontdir -e
/usr/X11R6/lib/X11/fonts/encodings -e
/usr/X11R6/lib/X11/fonts/encodings/large /usr/X11R6/lib/X11/fonts/100dpi
    ( [ -r /usr/X11R6/lib/X11/fonts/100dpi -a $( head -1
/usr/X11R6/lib/X11/fonts/100dpi ) -eq 0 ] && /usr/sbin/chkfontpath -q -r
/usr/X11R6/lib/X11/fonts/100dpi )  fi
} &> /dev/null || :

That should be "/usr/X11R6/lib/X11/fonts/100dpi/fonts.dir" in the [ -r ...
] test and the $( head -1 ... )

Same bug in at least XFree86-{75,100}dpi-fonts, but that part of the script
shouldn't actually be triggered by an upgrade AFAICS.

Couple of other possibilities (just in case you havn't already spotted
them) are:

Should that be "$2" not "$1" at the top?  I thought $1 was instances before
and $2 instances after?
Could chkfontpath be screwing up the ordering during the postinstall
stanza?
Comment 1 Mike A. Harris 2001-09-01 11:41:24 UTC 
The fs/config file is now %config instead of %config(noreplace).  This
means your original config file is now renamed to .rpmsave and the
one in the new X package replaces it.  With the existing tools, it
seems very difficult to come up with an adequate universal solution
to these config files.  What happens is we either put a new file in
place that is set up for the fonts that come with X, and in an
order that hopefully works best in most setups, or we leave the existing
one alone, and have to modify it which is very tricky and has proven
impossible to get right.

The current solution is deemed best for now, but alternate solutions
are being looked into for future releases.  This means that people who
have hand customized the xfs config will currently have to hand edit it
to tweak it to their liking.  The alternative was that people would have
to hand edit it to move other font paths around if they'd customized
them.  Hopefully future XFree86 releases will make this less painful.