Bug 1028557 - Upgrading/downgrading openldap makes openldap depend on openldap-devel
Summary: Upgrading/downgrading openldap makes openldap depend on openldap-devel
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
: 1028553 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2013-11-08 18:56 UTC by Jon Dufresne
Modified: 2015-01-19 12:26 UTC (History)
12 users (show)

Fixed In Version: openldap-2.4.39-5.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-03-24 12:27:15 UTC

Attachments (Terms of Use)

Description Jon Dufresne 2013-11-08 18:56:12 UTC
I noticed yum wanted to upgrade openldap-devel. As I do not use LDAP nor develop against it, I thought it was strange it was installed. So I removed it using:

$ sudo yum remove openldap-devel

This removed the following: openldap-devel, apr-util-devel, httpd-devel.

Now all yum commands fail with the following error:

$ curl http://fedoraproject.org/
curl: error while loading shared libraries: liblber-2.4.so.2: cannot open shared object file: No such file or directory

Comment 1 Kamil Dudka 2013-11-08 19:45:27 UTC
Thanks for the bug report!  This seems to be caused by incorrect packaging of ldap libraries.  liblber-2.4.so.2 from openldap is a symlink to liblber.so from openldap-devel instead of the regular file containing the library.  Consequently, if openldap-devel is removed, liblber-2.4.so.2 becomes a broken link.  Likewise with libldap-2.4.so.2.

Comment 2 Jan Synacek 2013-11-11 09:03:52 UTC
Works for me, with or without openldap-devel...

$ rpm -q openldap

$ rpm -q curl

$ rpm -q openldap-devel

$ curl fedoraproject.org
< the page is retrieved >

# yum remove openldap-devel

$ rpm -q openldap-devel
package openldap-devel is not installed

$ curl fedoraproject.org
< the page is retrieved >

Please, try updating/reinstalling openldap* and curl and try again.

Comment 3 Kamil Dudka 2013-11-11 09:40:12 UTC
The issues still exists on rawhide!  I did not check f19.

$ rpm -q openldap

$ sudo yum remove openldap-devel
  openldap-devel.x86_64 0:2.4.37-1.fc21


$ sudo yum remove openldap-devel
sudo: error in /etc/sudo.conf, line 0 while loading plugin `sudoers_policy'
sudo: unable to dlopen /usr/libexec/sudo/sudoers.so: (null)
sudo: fatal error, unable to load plugins

$ su -c 'yum remove openldap-devel'
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   liblber-2.4.so.2: cannot open shared object file: No such file or directory

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.5 (default, Oct  8 2013, 12:16:00) 
[GCC 4.8.1 20130920 (Red Hat 4.8.1-10)]

If you cannot solve this problem yourself, please go to 
the yum faq at:

Comment 4 Jan Synacek 2013-11-11 10:46:13 UTC
I can reproduce this on rawhide.

Comment 5 Jan Synacek 2013-11-11 10:49:18 UTC
Not reproducible on F20 either. Something must have changed during the rebase to 2.4.37. I will investigate.

Comment 6 Jan Synacek 2013-11-11 11:21:07 UTC
I have no idea how the symlink got corrupted... When the packages are built, the symlinks point to the right files: http://koji.fedoraproject.org/koji/buildinfo?buildID=474771.

Try 'yum reinstall openldap\*'. That worked for me.

Comment 7 Kamil Dudka 2013-11-11 14:02:28 UTC
True.  I see no broken symlinks any more after reinstalling the openldap package.

Comment 8 Jan Synacek 2013-11-11 14:48:41 UTC
I'll go ahead and close this bugzilla. If the problem manifests again, feel free to reopen this bug.

Comment 10 Jan Synacek 2014-03-21 08:04:09 UTC
I still don't see how this is a packaging bug. The symlinks in the build (http://koji.fedoraproject.org/koji/buildinfo?buildID=495976) are obviously correct and there is no symlink magic in the spec file either, apart from running ldconfig in %post.

However, I managed to reproduce this:

1. Install older openldap and openldap-devel (2.4.36-4, http://koji.fedoraproject.org/koji/buildinfo?buildID=473111)

2a. Upgrade openldap* to 2.4.39-2 (http://koji.fedoraproject.org/koji/buildinfo?buildID=495976)

2b. If openldap* on is already the latest version, yum downgrade openldap* (to 2.4.36-4) reproduces the problem as well.

3. After that, the symlinks are messed up:
$ ll /usr/lib64/libldap*
lrwxrwxrwx. 1 root root     10 Mar 21 08:52 /usr/lib64/libldap-2.4.so.2 -> libldap.so
-rwxr-xr-x. 1 root root 337576 Oct 23 07:58 /usr/lib64/libldap-2.4.so.2.9.2
lrwxrwxrwx. 1 root root     12 Mar 21 08:52 /usr/lib64/libldap_r-2.4.so.2 -> libldap_r.so
-rwxr-xr-x. 1 root root 362816 Oct 23 07:58 /usr/lib64/libldap_r-2.4.so.2.9.2
lrwxrwxrwx. 1 root root     22 Mar 21 08:52 /usr/lib64/libldap_r.so -> libldap_r-2.4.so.2.9.2
lrwxrwxrwx. 1 root root     20 Mar 21 08:52 /usr/lib64/libldap.so -> libldap-2.4.so.2.9.2

Expected state of the symlinks:
# dnf reinstall openldap
$ ll /usr/lib64/libldap*
lrwxrwxrwx. 1 root root     20 Mar 21 08:58 /usr/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.2
-rwxr-xr-x. 1 root root 337576 Oct 23 07:58 /usr/lib64/libldap-2.4.so.2.9.2
lrwxrwxrwx. 1 root root     22 Mar 21 08:58 /usr/lib64/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.9.2
-rwxr-xr-x. 1 root root 362816 Oct 23 07:58 /usr/lib64/libldap_r-2.4.so.2.9.2
lrwxrwxrwx. 1 root root     22 Mar 21 08:52 /usr/lib64/libldap_r.so -> libldap_r-2.4.so.2.9.2
lrwxrwxrwx. 1 root root     20 Mar 21 08:52 /usr/lib64/libldap.so -> libldap-2.4.so.2.9.2

Additional information:
Note that the library version changes when the problem reproduces. I just upgraded openldap from 2.4.36-4 to 2.4.39-2 and it looks like so:
$ ll /usr/lib64/libldap*
lrwxrwxrwx. 1 root root     10 Mar 21 09:00 /usr/lib64/libldap-2.4.so.2 -> libldap.so
-rwxr-xr-x. 1 root root 337576 Feb  4 10:08 /usr/lib64/libldap-2.4.so.2.10.2
lrwxrwxrwx. 1 root root     12 Mar 21 09:00 /usr/lib64/libldap_r-2.4.so.2 -> libldap_r.so
-rwxr-xr-x. 1 root root 362816 Feb  4 10:08 /usr/lib64/libldap_r-2.4.so.2.10.2
lrwxrwxrwx. 1 root root     23 Mar 21 09:00 /usr/lib64/libldap_r.so -> libldap_r-2.4.so.2.10.2
lrwxrwxrwx. 1 root root     21 Mar 21 09:00 /usr/lib64/libldap.so -> libldap-2.4.so.2.10.2

Comment 11 Jan Synacek 2014-03-21 08:09:32 UTC
Moving to glibc, as this looks like an ldconfig bug.

Comment 12 Richard W.M. Jones 2014-03-21 09:06:21 UTC
The description in comment 10 would make sense as I have
upgraded openldap between versions several times since this
machine was installed.

Comment 13 Carlos O'Donell 2014-03-22 08:10:58 UTC
This is not a bug in ldconfig, but certainly perhaps a failing in the core runtime documentation detailing for devleopers how these symlinks should be laid out.

If the -devel package provided symlinked *.so file does not point to SONAME, then ldconfig considers it to be a symlink created by the user and a valid target for creating a symlink *to*, and this will cause problems during a downgrade. I can walk you through the entire process, but it's a long and slow description of what yum does during the downgrade with old and new packages partially installed and ldconfig run as part of the downgraded packages %post.

In practice therefore this is an openldap-devel bug. It symlinks the *.so files to the actual final *.so.x.y.z files, and that breaks downgrading. The *.so files provided for use by the static linker should always point at the SONAME file. That is to say that with openldap and openldap-devel installed the final file layout for libldap* should look like this:
libldap_r.so -> libldap_r-2.4.so.2
libldap.so -> libldap-2.4.so.2
libldap-2.4.so.2 -> libldap-2.4.so.2.10.2
libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.2

e.g. libldap.so (ld(1) name) -> SONAME -> Arbitrary package library name.

The existing ldconfig code is what it is, and has been in place and in effect for years as part of the core runtime, changing it now would require serious consideration and a strong rationale.

Thus my only suggestion is to fix openldap-devel.

If you have any more questions please ask.

Any other -devel packages that behave the same way are going to break in the same way.

It is obviously hard to enforce this kind of rule because the package may have unversioned libraries.

Comment 14 Jan Synacek 2014-03-24 10:40:08 UTC
Thank you for the explanation, Carlos.

Those symlinks are created like that by libtool. Should I consider it a libtool flaw, then? Or is there a way to tell libtool not to do it? I didn't find any.

Anyway, openldap fix incoming. Thanks again!

Comment 15 Jan Synacek 2014-03-24 11:39:01 UTC

The symlinks should now be correctly pointing to the SONAME files.
$ ll /usr/lib64/libldap*
lrwxrwxrwx. 1 root root     21 Mar 24 11:35 /usr/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.10.2
-rwxr-xr-x. 1 root root 337576 Mar 24 11:29 /usr/lib64/libldap-2.4.so.2.10.2
lrwxrwxrwx. 1 root root     23 Mar 24 11:35 /usr/lib64/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.2
-rwxr-xr-x. 1 root root 362816 Mar 24 11:29 /usr/lib64/libldap_r-2.4.so.2.10.2
lrwxrwxrwx. 1 root root     18 Mar 24 11:35 /usr/lib64/libldap_r.so -> libldap_r-2.4.so.2
lrwxrwxrwx. 1 root root     16 Mar 24 11:35 /usr/lib64/libldap.so -> libldap-2.4.so.2

Comment 16 Paul Howarth 2014-03-24 11:57:30 UTC
Well they would be if the build had succeeded. Unfortunately all koji builds seem to be failing at the moment with a fedpkg issue:

DEBUG util.py:331:  Executing command: ['fedpkg', 'sources'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:281:  Could not execute sources: __init__() got an unexpected keyword argument 'module_name'
DEBUG util.py:371:  Child return code was: 1

Comment 17 Jan Synacek 2014-03-24 12:00:48 UTC
Yes, I attempted to build the package twice and it resulted in a weird error like the one above. I'll build the package once this issue has been resolved.

Comment 18 Paul Howarth 2014-03-24 12:05:03 UTC
It seems to be working again now, try again.

Comment 19 Richard W.M. Jones 2015-01-19 12:26:30 UTC
*** Bug 1028553 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.