Bug 122973 - Dual fontconfig packages erroneuously show /etc/fonts/fonts.conf as modfied
Dual fontconfig packages erroneuously show /etc/fonts/fonts.conf as modfied
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: fontconfig (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
:
: 123579 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-10 16:51 EDT by Bill Peck
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-09 15:08:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Peck 2004-05-10 16:51:41 EDT
Description of problem:
Dual fontconfig packages erroneuously show /etc/fonts/fonts.conf as
modfied

Version-Release number of selected component (if applicable):
fontconfig-2.2.1-6.0
fontconfig-2.2.1-8.0

How reproducible:
Everytime

Steps to Reproduce:
1. install rhel3-U1 on any arch but x86
2. rpm -qV fontconfig
3.
  
Actual results:
..5....T c /etc/fonts/fonts.conf

Expected results:
No md5sum difference or Time difference

Additional info:
prevents up2date from updating to newer versions of fontconfig.
Comment 1 Owen Taylor 2004-05-10 17:03:21 EDT
This is bug 118182, a patch from the FC2 RPM just needs to be added
for the RHEL3 package.
Comment 2 Michael Shuler 2004-05-28 18:01:31 EDT
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
utilities.

Kind Regards,
Michael Shuler
Comment 3 Tom Weeks 2004-06-29 15:59:22 EDT
Agreed..

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:
/usr/bin/artscat
/usr/bin/artsd
/usr/bin/artsdsp
/usr/bin/artsplay
/usr/bin/artsrec
/usr/bin/artsshell
/usr/bin/artswrapper
/usr/bin/testdhandle
/usr/bin/artscat
/usr/bin/artsd
/usr/bin/artsdsp
/usr/bin/artsplay
/usr/bin/artsshell
/usr/bin/artswrapper

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 
future...

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".

Tweeks
Comment 4 Owen Taylor 2004-08-04 10:51:38 EDT
*** Bug 123579 has been marked as a duplicate of this bug. ***
Comment 5 Owen Taylor 2004-09-02 15:09:07 EDT
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.
Comment 6 Tom Weeks 2004-09-03 00:10:34 EDT
> 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   
Comment 7 Owen Taylor 2004-09-09 15:08:45 EDT
Fixed in fontconfig-2.2.1-13 in RHEL3-U3

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