Bug 106747 - apps linked against v2 and v3 of libcom_err.so
apps linked against v2 and v3 of libcom_err.so
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Florian La Roche
:
: 106842 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-10 01:20 EDT by Justin Moore
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-14 00:34:58 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 Justin Moore 2003-10-10 01:20:44 EDT
Description of problem:
Several applications -- such as cupsd, httpd, and sendmail -- are linked against
both version 2 /and/ version 3 of libcom_err.so.  Only libcom_err.so.2 comes in
Fedora test2 (0.94), in the e2fsprogs package.

Version-Release number of selected component (if applicable):
e2fsprogs-1.34-1
httpd-2.0.47-6
cups-1.1.19-12
sendmail-8.12.10-1.1

How reproducible:
Always (as far as I can tell)

Steps to Reproduce:
1. I upgraded from stock RH9 to Fedora Core test 2 (0.94)
2. Reboot into fedora system
3.
    
Actual results:
httpd, cupsd, and sendmail did not start (missing shared library).

Expected results:
They should have started.

Additional info:
Doing an `ldd <APP>`, where <APP> is either cupsd, httpd, or sendmail shows that
all three daemons are linked against both libcom_err.so.2 and libcom_err.so.3.
Comment 2 Bill Nottingham 2003-10-10 11:22:33 EDT
I only see one version of libcom_err being pulled in on my box with that version
of sendmail and cups. It appears your upgrade didn't upgrade something correctly?

What library is bringing in the wrong libcomm_err dep?
Comment 3 Justin Moore 2003-10-10 11:32:25 EDT
Which version of libcom_err is on your box?  Also, keep in mind that I upgraded
directly from RH9 to Fedora test2.  Most of the binaries in /usr/sbin are linked
against both v2 and v3 of libcom_err.  I'm not seeing any packages that depend
on libcom_err v3, but several that depend on v2.

I'd be more specific, but I don't have the laptop in front of me right now.  I'm
at work and I left it at home this morning.
Comment 4 Bill Nottingham 2003-10-10 12:28:40 EDT
I only have .2 on my install here.
Comment 5 Justin Moore 2003-10-10 17:29:44 EDT
openssl-0.9.7a-20 depends on libcom_err.so.3, but anaconda/rpm/whatever didn't
install any package that provides libcom_err.so.3.  Now that I'm actually
learning to read directions, I check my /root/upgrade.log and found lines like
these there:

Upgrade Dependency: Needs (('openssl', '0.9.7a', '20'), ('libcom_err.so.3',
None), 0, None, 0), automatically added.

There's another line like that for pine 4.44-19.90.0
Comment 6 Daniel Thompson 2003-10-11 03:15:38 EDT
This problem occurs when upgrading a RH9.0 system that has an updated version of
openssl present.

openssl from the RH9.0 errate is 0.9.7a-20 (and depends on libcom_err.so.3) is
not  upgraded with the version from Fedora core 0.9.7a-17 (linked against the
correct version of the library).

You can fix a broken system by upgrading with --oldpackage using the version of
OpenSSH supplied with Fedora. THIS WILL EFFECTIVELY REMOVE A SECURITY PATCH.
Take care!

The pine issue is a bit of a red herring - pine has been removed from Fedora so
its breakage is not supprising.
Comment 7 Justin Moore 2003-10-11 20:51:47 EDT
I did the update with --oldpackage and it worked.
Comment 8 Bill Nottingham 2003-10-14 00:34:58 EDT
Current openssl for Cambridge is 0.9.7a-23.
Comment 9 Bill Nottingham 2003-10-14 00:41:04 EDT
*** Bug 106842 has been marked as a duplicate of this bug. ***

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