Bug 112804

Then this is either a bug in the old XFree86 package that it left
the files around, or in rpm.  Two versions of the library in different
location is certainly a bug.
You can undo the ldconfig change by putting
/lib
/usr/lib
at the beginning of /etc/ld.so.conf and rerunning ldconfig.
ldconfig has been changed so that you can choose where the standard
directories are located in the library search path and to match
behaviour of ldconfigs separate from glibc.  Without that, the system
directories were always first and you couldn't override anything.

The change in ldconfig you mention explains my problem. In my
/etc/ld.so.conf there is a line:

/usr/X11R6/lib

near the top. Thus the "old" ldconfig found libfreetype.so.6.2 in
/usr/lib, whereas the "new" ldconfig finds the one in /usr/X11R6/lib.

I seem to remember that a long time ago I compiled and installed
XFree86 4.2 from source (downloaded from www.xfree86.org) . The stale
libraries in /usr/X11R6/lib may be a leftover.

While I can see the utility of the ldconfig change, I would submit
that it might be prudent to include /lib and /usr/lib in
/etc/ld.so.conf, so that the default behavior of ldconfig isn't changed. 

Our XFree86 packages do not supply any libfreetype.* libraries at
all in any location.  If you are having a conflict with libraries
located in the /usr/X11R6/lib directory, then you have either:

1) At some point in time previously, you have installed XFree86
   binary installation from XFree86.org in tarball format, or
   compiled and installed it yourself from raw source.  This will
   install libfreetype in that location, and RPM will not know
   anything about it, nor will rpm uninstall it or modify it.

or

2) At some point in time you have installed a non-official build
   of XFree86 either in rpm format or not, such as from rawhide,
   or some other rpm repository, which may have conflicted with
   your system.

If the files were managed by rpm however, then they would have
been uninstalled properly, so #2 is only possible if you've used
--nodeps --force or other dangerous rpm commandline options.

If neither of the above situations are the case, then your system
is not a clean OS installation, and may have corrupted rpm database
or something else over time.  If you do a clean OS installation of
Red Hat Linux 9, you will not have any libfreetype in /usr/X11R6/lib,
nor should you have libfreetype in that directory on any previous
official Red Hat Linux OS release, nor with any upgrades, nor OS
to OS upgrades.  All files supplied in the rpm packages, are owned
by the rpm packages in any case, so even if such libraries were
supplied in developmental builds accidentally in the past (they may
have been), they would _definitely_ be removed upon upgrade.

Closing bug as NOTABUG.

To refute your first statement:

$ rpm -ql freetype-2.1.3-6 | grep "/usr/lib"
/usr/lib/libfreetype.so.6
/usr/lib/libfreetype.so.6.3.2
/usr/lib/libttf.so.2
/usr/lib/libttf.so.2.3.0

This is on a box with RH9 installed from scratch. Thus the RedHat
XFree86 packages most certainly provide the libfreetype.* libraries
(which they have to, otherwise X wouldn't work). If you meant to say
that the RedHat XFree86 packages never provided libfreetype* in
/usr/X11R6/lib, then I'll accept that.

As I said, I believe that in the past (about 18 months ago) I compiled
Xfree86 4.2 from sources from xfree86.org. This source put
libfreetype* in /usr/X11R6/lib.

My beef is not with your XFree86 packages, but with glibc. When a
package goes from version 2.3.2-27.9 to 2.3.2-27.9.7, then I do would
expect to see only minor changes. I would contend such a minor version
change should not break any system, however badly configured it may
be. It turns out that ldconfig changed the default library search
order. This I believe is a major change and it should not have been
implemented in the way it was. It broke two of my systems and from
Google I don't think I was the only one. I think that either the
ldconfig change should have been deferred or /etc/ld.so.conf should
have been changed as well to ensure the previous library search order
was maintained.

On more note on XFree86: since the official XFree86 sources put
libfreetype.* in /usr/X11R6/lib, you may want to consider to have your
rpm check for this. When you do things differently from the folks who
officially support XFree86, you should not ignore the potential
consequences for your customers.

> This is on a box with RH9 installed from scratch. Thus the RedHat
> XFree86 packages most certainly provide the libfreetype.* libraries

What you've shown above, is that you have the freetype library
installed, from the "freetype" rpm package, which has absolutely
nothing to do with XFree86.  freetype is a standalone font
library http://www.freetype.org which is included with Red Hat
operating systems as many pieces of software directly use freetype,
including XFree86 and others, however XFree86 is not the only
piece of software that uses freetype.  Our freetype package is _not_
part of XFree86 packaging, but is a separate standalone package,
as you've shown above.  XFree86 components do indeed require
libfreetype to be present on the system during compile time and
runtime, however there is absolutely no requirement whatsoever
that XFree86 supply its own libfreetype.

XFree86 comes with freetype source code in its source tree, however
we do _not_ use the freetype that comes with XFree86.  We use the
system supplied freetype from our freetype package, by enabling
the XFree86 host.def "HasFreetype2 YES" option during compilation,
which forces XFree86 to compile itself against the system supplied
freetype.  It thus never compiles nor uses its own internal
freetype.

> If you meant to say that the RedHat XFree86 packages never
> provided libfreetype* in /usr/X11R6/lib, then I'll accept that.

No, I meant specifically that *official* Red Hat XFree86 packages
released either as part of one of our OS distribution CDs in their
final form, as well as any updates to Red Hat XFree86 packages
that have been released by us, have never included libfreetype
at all period, not in /usr/X11R6/lib, and not in /usr/lib.  If there
has ever been an XFree86 package that we've shipped that did in 
fact contain the libfreetype libraries, then it is news to me.

Your above query does show that you have freetype installed, and
that it is installed in /usr/lib, however that has nothing to do
with XFree86 at all, as the "freetype" rpm package, as I've stated
above, is not part of XFree86 any more than glibc is.

> As I said, I believe that in the past (about 18 months ago) I
> compiled Xfree86 4.2 from sources from xfree86.org. This source
> put libfreetype* in /usr/X11R6/lib.

And that is exactly what I stated above is your problem in comment
#3 above, when I stated:

-----8<---------------------------------------------------------
1) At some point in time previously, you have installed XFree86
   binary installation from XFree86.org in tarball format, or
   compiled and installed it yourself from raw source.  This will
   install libfreetype in that location, and RPM will not know
   anything about it, nor will rpm uninstall it or modify it.
-----8<---------------------------------------------------------

> My beef is not with your XFree86 packages, but with glibc.

Your problem is solely caused by you manually installing XFree86
from source code, and allowing it to install whatever libraries
it wanted to, wherever it felt like doing so, regardless of wether
or not the system already supplied the proper libraries or not.

This is not a glibc problem, nor an XFree86 problem.  If you replace
major core parts of the operating system from raw source code,
such as freetype, XFree86, or any of a number of other major core
OS components, your operating system may have at one time been
a Red Hat Linux OS installation, but once you've replaced core
components it is no longer Red Hat Linux, but rather something that
resembles Red Hat Linux and is originally based upon it.

We do not support users systems that have replaced major OS
components with unofficial builds compiled by the user from source
code or downloaded from elsewhere.

> On more note on XFree86: since the official XFree86 sources put
> libfreetype.* in /usr/X11R6/lib, you may want to consider to have
> your rpm check for this.

Absolutely not.  The system comes with freetype, and you are
expected to use the system supplied freetype, as supplied by Red Hat,
if you want your system to be supported in any way.

> When you do things differently from the folks who officially
> support XFree86, you should not ignore the potential
> consequences for your customers.

XFree86.org supports XFree86 on a large number of OS platforms and
CPU architectures.  Many of the libraries which XFree86 and its
components require in order to compile and/or run, do not come
with many of those operating systems, as all of the software is
open source software, and many operating systems do not come with
any OSS software at all.  As such, XFree86.org has traditionally
done 2 things to work around this problem:

1) They have made XFree86 intentionally only require and/or use
   libraries which are under a license which is compatible with
   the XFree86 MIT license.

2) They include the library sources with XFree86 so that systems that
   do not supply the libraries that XFree86 requires, can still
   compile and use XFree86, as it supplies these libraries itself
   for systems that do not provide them, and does so under a
   license compatible with XFree86 itself.

In the case of freetype, it _is_ supplied with the system, and is
likely supplied with every Linux OS out there.  Any usage of the
XFree86 supplied freetype is totally non-standard, and is just
asking for problems.  XFree86.org does _not_ set the standard.

If you are wanting to compile XFree86 from source, then you should
be seeking support for that from XFree86.org directly, not from
Red Hat.  What you are asking us to support, we very much do not
support.  You _MUST_ use the system supplied libraries and software
we supply if you want your system supported.

Please contact your Red Hat customer support account manager
directly if you require clarification on the boundaries of
what your support contract does and does not cover, and they'll
be happy to clarify any confusion that may be present.