Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 693716

Summary:	rpm -V fails when upgrading with openldap-devel installed
Product:	Red Hat Enterprise Linux 6	Reporter:	Ondrej Moriš <omoris>
Component:	openldap	Assignee:	Jan Vcelak <jvcelak>
Status:	CLOSED ERRATA	QA Contact:	Ondrej Moriš <omoris>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.1	CC:	borgan, ebenes, jgalipea, jplans, jvcelak, mkasik, ohudlick, ovasik, pmatilai, syeghiay, tsmetana
Target Milestone:	rc	Keywords:	TestBlocker
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openldap-2.4.23-15.el6	Doc Type:	Bug Fix
Doc Text:	- openldap-devel package installed - upgrading older openldap package (before libraries were moved from /usr/lib to /lib) to a new version (after the libraries were moved) confused ldconfig, which mixed up openldap symlinks in /usr/lib - only -devel *.so symlinks were left in /usr/lib, the rest of the libraries resides in /usr - symlinks to openldap libraries are created correctly after the upgrade from old version of openldap, when openldap-devel package is installed	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-19 14:00:08 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:	680202
Bug Blocks:	682670

Description Ondrej Moriš 2011-04-05 12:07:15 UTC

Description of problem:

See below.

Version-Release number of selected component (if applicable):

NEW: openldap-2.4.23-14.el6
OLD: openldap-devel-2.4.19-15.el6_0.2

How reproducible:

Always.

Steps to Reproduce:

1. Install all old openldap packages.
2. Upgrade all packages to new version.
3. rpm -V openldap
  
Actual results:

....L....    /usr/lib/liblber-2.4.so.2
....L....    /usr/lib/libldap-2.4.so.2
....L....    /usr/lib/libldap_r-2.4.so.2

Expected results:

Success.

Additional info:

* when devel package is not installed, problem does not occur
* see also erratum RHBA-2011:10623
* setting high priority since it is blocking tps-rpmtest in many errata

Comment 1 Eduard Benes 2011-04-05 15:40:35 UTC

Looks like the problem is with this:

.qa.[root@x86-64-6c-m1 tps]# ll /lib64/liblber-2.4.so.2
lrwxrwxrwx 1 root root 20 Apr  5 11:28 /lib64/liblber-2.4.so.2 -> liblber-2.4.so.2.5.6
.qa.[root@x86-64-6c-m1 tps]# ll /usr/lib64/liblber-2.4.so.2
lrwxrwxrwx 1 root root 10 Apr  5 11:28 /usr/lib64/liblber-2.4.so.2 -> liblber.so

.qa.[root@x86-64-6c-m1 tps]# readlink -f /lib64/liblber-2.4.so.2
/lib64/liblber-2.4.so.2.5.6
.qa.[root@x86-64-6c-m1 tps]# readlink -f /usr/lib64/liblber-2.4.so.2
/lib64/liblber-2.4.so.2.5.6

Comment 2 Jan Vcelak 2011-04-05 17:03:01 UTC

Eduard, I think this is correct. Or am I missing something?

Libraries were moved from /usr/lib to /lib (bz #548475):

/lib/liblber-2.4.so.2 -> liblber-2.4.so.2.5.6
/lib/liblber-2.4.so.2.5.6
/lib/liblber.so -> liblber-2.4.so.2.5.6
/lib/libldap-2.4.so.2 -> libldap-2.4.so.2.5.6
/lib/libldap-2.4.so.2.5.6
/lib/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.5.6
/lib/libldap_r-2.4.so.2.5.6
/lib/libldap_r.so -> libldap_r-2.4.so.2.5.6
/lib/libldap.so -> libldap-2.4.so.2.5.6
/lib/libldif-2.4.so.2 -> libldif-2.4.so.2.5.6
/lib/libldif-2.4.so.2.5.6
/lib/libldif.so -> libldif-2.4.so.2.5.6

Newly created symlinks in /usr/lib referes to the new location:

/usr/lib/liblber-2.4.so.2 -> /lib/liblber-2.4.so.2
/usr/lib/liblber-2.4.so.2.5.6 -> /lib/liblber-2.4.so.2.5.6
/usr/lib/liblber.so -> /lib/liblber.so
/usr/lib/libldap-2.4.so.2 -> /lib/libldap-2.4.so.2
/usr/lib/libldap-2.4.so.2.5.6 -> /lib/libldap-2.4.so.2.5.6
/usr/lib/libldap_r-2.4.so.2 -> /lib/libldap_r-2.4.so.2
/usr/lib/libldap_r-2.4.so.2.5.6 -> /lib/libldap_r-2.4.so.2.5.6
/usr/lib/libldap_r.so -> /lib/libldap_r.so
/usr/lib/libldap.so -> /lib/libldap.so
/usr/lib/libldif-2.4.so.2 -> /lib/libldif-2.4.so.2
/usr/lib/libldif-2.4.so.2.5.6 -> /lib/libldif-2.4.so.2.5.6
/usr/lib/libldif.so -> /lib/libldif.so

During the update with openldap-devel installed, something goes wrong and RPM produces following files (which make no sense):

/usr/lib/liblber-2.4.so.2 -> liblber.so
/usr/lib/libldap-2.4.so.2 -> libldap.so
/usr/lib/libldap_r-2.4.so.2 -> libldap_r.so

'yum reinstall openldap' fixes it.

I don't know if this is OpenLDAP or RPM bug.

Comment 3 Panu Matilainen 2011-04-06 07:25:10 UTC

The problem is likely to be those versioned symlinks in /usr/lib(64) that point to files of same name in /lib(64). Not sure if its ldconfig or rpm that gets mixed up there but you shouldn't add such links: the standard practise is to move the actual library + versioned symlinks to /lib(64) and only leave the unversioned libfoo.so links in -devel to the original /usr/lib(64) locations.

Comment 4 Jan Vcelak 2011-04-06 07:53:53 UTC

(In reply to comment #3)
> The problem is likely to be those versioned symlinks in /usr/lib(64) that point
> to files of same name in /lib(64). Not sure if its ldconfig or rpm that gets
> mixed up there but you shouldn't add such links: the standard practise is to
> move the actual library + versioned symlinks to /lib(64) and only leave the
> unversioned libfoo.so links in -devel to the original /usr/lib(64) locations.

We need versioned symlinks in /usr/lib as well. Otherwise it will break acroread, which uses some strange dependencies, and maybe some more.

I can try updating the symlinks in /usr/lib to refer directly to the versioned libraries in /lib (instead of referring to the files with the same name). Maybe it will bypass the problem.

Comment 5 Eduard Benes 2011-04-07 09:37:47 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > The problem is likely to be those versioned symlinks in /usr/lib(64) that point
> > to files of same name in /lib(64). Not sure if its ldconfig or rpm that gets
> > mixed up there but you shouldn't add such links: the standard practise is to
> > move the actual library + versioned symlinks to /lib(64) and only leave the
> > unversioned libfoo.so links in -devel to the original /usr/lib(64) locations.
> 
> We need versioned symlinks in /usr/lib as well. Otherwise it will break
> acroread, which uses some strange dependencies, and maybe some more.
> 
> I can try updating the symlinks in /usr/lib to refer directly to the versioned
> libraries in /lib (instead of referring to the files with the same name). Maybe
> it will bypass the problem.

OK, let's try it on some scratch build. Thanks

Comment 7 Jan Vcelak 2011-04-07 15:43:15 UTC

(In reply to comment #4)
> I can try updating the symlinks in /usr/lib to refer directly to the versioned
> libraries in /lib (instead of referring to the files with the same name). Maybe
> it will bypass the problem.

This doesn't work.

# rpm -qa openldap\*
openldap-devel-2.4.19-15.el6_0.2.i686
openldap-servers-2.4.19-15.el6_0.2.i686
openldap-clients-2.4.19-15.el6_0.2.i686
openldap-2.4.19-15.el6_0.2.i686

# rpm -qV openldap && echo ok
ok

update to scratch build

# rpm -qa openldap\*
openldap-devel-2.4.23-15.el6.i686
openldap-clients-2.4.23-15.el6.i686
openldap-2.4.23-15.el6.i686
openldap-servers-2.4.23-15.el6.i686

# rpm -qV openldap && echo ok
....L....    /usr/lib/liblber-2.4.so.2
....L....    /usr/lib/libldap-2.4.so.2
....L....    /usr/lib/libldap_r-2.4.so.2

reinstall new packages

# rpm -qV openldap && echo ok
ok

actual list of libraries:

/lib/liblber-2.4.so.2 -> liblber-2.4.so.2.5.6
/lib/liblber-2.4.so.2.5.6
/lib/liblber.so -> liblber-2.4.so.2.5.6
/lib/libldap-2.4.so.2 -> libldap-2.4.so.2.5.6
/lib/libldap-2.4.so.2.5.6
/lib/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.5.6
/lib/libldap_r-2.4.so.2.5.6
/lib/libldap_r.so -> libldap_r-2.4.so.2.5.6
/lib/libldap.so -> libldap-2.4.so.2.5.6
/lib/libldif-2.4.so.2 -> libldif-2.4.so.2.5.6
/lib/libldif-2.4.so.2.5.6
/lib/libldif.so -> libldif-2.4.so.2.5.6

/usr/lib/liblber-2.4.so.2 -> /lib/liblber-2.4.so.2.5.6
/usr/lib/liblber-2.4.so.2.5.6 -> /lib/liblber-2.4.so.2.5.6
/usr/lib/liblber.so -> /lib/liblber-2.4.so.2.5.6
/usr/lib/libldap-2.4.so.2 -> /lib/libldap-2.4.so.2.5.6
/usr/lib/libldap-2.4.so.2.5.6 -> /lib/libldap-2.4.so.2.5.6
/usr/lib/libldap_r-2.4.so.2 -> /lib/libldap_r-2.4.so.2.5.6
/usr/lib/libldap_r-2.4.so.2.5.6 -> /lib/libldap_r-2.4.so.2.5.6
/usr/lib/libldap_r.so -> /lib/libldap_r-2.4.so.2.5.6
/usr/lib/libldap.so -> /lib/libldap-2.4.so.2.5.6
/usr/lib/libldif-2.4.so.2 -> /lib/libldif-2.4.so.2.5.6
/usr/lib/libldif-2.4.so.2.5.6 -> /lib/libldif-2.4.so.2.5.6
/usr/lib/libldif.so -> /lib/libldif-2.4.so.2.5.6

Comment 9 Jan Vcelak 2011-04-07 16:38:30 UTC

The problem is with ldconfig, not RPM. I removed ldconfig from all scriptlets and libraries were created well after the upgrade.

Comment 10 Jan Vcelak 2011-04-07 17:21:41 UTC

Removing unversioned (devel) *.so files from new location in /lib while leaving them in /usr/lib didn't help.

Comment 30 Jan Vcelak 2011-04-20 17:16:50 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
- openldap-devel package installed
- upgrading older openldap package (before libraries were moved from /usr/lib to /lib) to a new version (after the libraries were moved) confused ldconfig, which mixed up openldap symlinks in /usr/lib
- only -devel *.so symlinks were left in /usr/lib, the rest of the libraries resides in /usr
- symlinks to openldap libraries are created correctly after the upgrade from old version of openldap, when openldap-devel package is installed

Comment 31 errata-xmlrpc 2011-05-19 14:00:08 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0673.html