Description of problem:
Dual fontconfig packages erroneuously show /etc/fonts/fonts.conf as
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install rhel3-U1 on any arch but x86
2. rpm -qV fontconfig
..5....T c /etc/fonts/fonts.conf
No md5sum difference or Time difference
prevents up2date from updating to newer versions of fontconfig.
This is bug 118182, a patch from the FC2 RPM just needs to be added
for the RHEL3 package.
This particular dual-architecture package also creates a problem with
attempting to install software dependant on an alternate library
architecture. For instance, on a fresh AS-3/AMD64 install, one cannot
install java-1.4.1 from RHN. The resulting failure, when attempting
to fetch and install fontconfig-2.2.1-8.0.i386.rpm with 'up2date -i
java-1.4.1-ibm' (fontconfig-2.2.1-8.0.x86_64.rpm is currently install):
file /etc/fonts/fonts.conf from install of fontconfig-2.2.1-8.0
conflicts with file from package fontconfig-2.2.1-8.0
Manual installation of the RPM complains similarly.
Additionally, without the capabilities of specifying an architecture
for downloading the i386 RPM, the up2date utility politely indicates
that the package is already updated, and one is forced to dig through
packages in the RHN website for manual downloading.
If multiple package architecture are to be offered with an OS, then
the ability to specify the desired architecture must be included in
I just went to install a package on an Optron server that
required the 32 bit version of libartsc.so.0 (arts-2.2.2-11
package). The thing is... I already had the 64 bit version
installed.. and up2date (or RPM) will not differentiate between
them... And get this.. While the 32 bit libraries might go in
/usr/lib/ and the 64 bit ones go in /usr/lib64/ just fine.. the
BINARIES BOTH have to go in /bin:
Which means to even get my app to WORK.. I have to first install
the 64 bit RPM using up2date.. then jump over to a 32 bit
platform.. DL the 32 bit version of the RPM, move it over, and
--force install it over top the 64 bit binary version.. thus
breaking the RPM MD5SUMs... Which, of course, will keep up2date
from updating ANY packages that require this package in the
The house of cards comes crashing down...
This is a fundamental problem of the RPM system, upon which
up2date is built.
This is a bit more than "a font problem".
*** Bug 123579 has been marked as a duplicate of this bug. ***
Tom - there is a standard way that 32-bit packages work on
a x86_64 system ... for instance, 64-bit executables are always
preferred to 32-bit executables, without file conflicts.
Some packages (here fontconfig) have needed fixing for this,
but there is a defined way it is supposed to work.
We're gradually working on fixing RHEL3 libraries through the
update process. fontconfig will be fixed in U3. arts isn't
a common library for 3rd party applications, so I'm not sure
if we're planning to release an update for it or not.
If you are actually testing with Fedora and the 32-bit and 64-bit
versions of the arts package don't install together, you should make
sure there is an open bugs for that.
> If you are actually testing with Fedora and the 32-bit and 64-bit > versions of the arts package don't install together, you should > make sure there is an open bugs for that. Not Fedora... RH-EL3 on Opteron. I had to install the 32 bit version of arts because up2date was ignorantly looking for that version of the arts library even thought the 64 bit version was already there (in /bin and /usr/lib64/). I had to move over to a 32bit system, force a download of the binary 32 bit RPM, move it over to the opteron, force the install (overwriting the 64 bit files in /bin, thus breaking the 64 bit version of arts, but satisfying the wacky dependency). ONLY THEN would up2date/RPM be satisfied and allow a full update to the system. This was a moth or so ago... if I run into it again, I'll open a bug for it. Thanks for the feedback though. Tweeks
Fixed in fontconfig-2.2.1-13 in RHEL3-U3