Bug 52775 - Ordering of 75/100dpi fonts lost during package updates
Summary: Ordering of 75/100dpi fonts lost during package updates
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-28 23:03 UTC by Bill Crawford
Modified: 2007-04-18 16:36 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-28 23:03:36 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 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
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

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.

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