Bug 741935

Summary: curl update breaks yum
Product: Red Hat Enterprise Linux 6 Reporter: Kamil Dudka <kdudka>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Jiri Pospisil <jpospisi>
Severity: high Docs Contact:
Priority: high    
Version: 6.2CC: ddumas, ebenes, jpospisi, mvadkert, prc
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: curl-7.19.7-30.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 642796 Environment:
Last Closed: 2013-02-21 10:09:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 642796    
Bug Blocks: 749873    

Description Kamil Dudka 2011-09-28 14:24:40 UTC
+++ This bug was initially created as a clone of Bug #642796 +++

Description of problem:

After an update of libcurl to version 7.21.2-1.fc15 any attempt to run yum fails as follows:

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /usr/lib64/libcurl.so.4: undefined symbol: libssh2_scp_send64

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7 (r27:82500, Sep 29 2010, 23:01:31) 
[GCC 4.5.1 20100924 (Red Hat 4.5.1-4)]


Reversing updates of curl and libcurl to the previous 7.21.2-1.fc15 makes yum to work again.


Version-Release number of selected component (if applicable):
curl-7.21.2-1.fc15

How reproducible:
always

--- Additional comment from michal on 2010-10-13 23:14:26 CEST ---

(In reply to comment #3)
> You need to update libssh2 first.

So how about ensuring that this "first" really happens?  Otherwise you have a situation like now when curl packages are already updated and one need to fish in koji to repair the damage.

--- Additional comment from michal on 2010-10-14 01:59:20 CEST ---

(In reply to comment #6)
> I am just following the packaging guidelines [1]: "Packages must not contain
> explicit Requires on libraries except when absolutely necessary."

Do they have to be explicit in this case?  It seems to me that there were some ABI changes, or otherwise you would not complain about "undefined symbol" which apparently is provided elsewhere, but soname was not touched.  I am possibly
missing something.

> From my point of view, it's just a regular rawhide breakage,

A rawhide is rawhide.  Agreed.  Only if something of that sort would happen during release updates (not unthinkable with a little help from bodhi even if you
had all updates in 'testing') then you would end up with a crowd of quite unhappy users most quite baffled with how to recover.

--- Additional comment from paul on 2010-10-14 14:23:50 CEST ---

Created attachment 453445 [details]
Enforce versioned libssh2 dependency for libcurl

This is not the first time this problem has occurred (see also Bug #525002), so I prefer a more generic solution to prevent it happening again. I propose adding a versioned dependency in libcurl for the version of libssh2 that it was built against. This ensures that any symbols available at build-time will also be available at run-time. It also allows the Rawhide SRPM to be usefully rebuilt on older releases, as the resulting package will have a dependency reflecting the version of libssh2 available in the release it was built for.

In fact, this could be further improved by using libssh2%{?_isa} rather than plain libssh2 so we ensure we get the right-arch version of libssh2.

--- Additional comment from paul on 2010-10-14 17:30:44 CEST ---

Should be fixed in curl-7.21.2-2.fc15

Comment 3 Suzanne Logcher 2012-02-14 23:16:47 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 14 errata-xmlrpc 2013-02-21 10:09:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0393.html