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
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.
Works for me, with or without openldap-devel... $ rpm -q openldap openldap-2.4.36-4.fc19.x86_64 $ rpm -q curl curl-7.29.0-12.fc19.x86_64 $ rpm -q openldap-devel openldap-devel-2.4.36-4.fc19.x86_64 $ 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.
The issues still exists on rawhide! I did not check f19. $ rpm -q openldap openldap-2.4.37-1.fc21.x86_64 $ sudo yum remove openldap-devel [...] Removed: openldap-devel.x86_64 0:2.4.37-1.fc21 Complete! $ 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' Password: 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: http://yum.baseurl.org/wiki/Faq
I can reproduce this on rawhide.
Not reproducible on F20 either. Something must have changed during the rebase to 2.4.37. I will investigate.
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.
True. I see no broken symlinks any more after reinstalling the openldap package.
I'll go ahead and close this bugzilla. If the problem manifests again, feel free to reopen this bug.
https://lists.fedoraproject.org/pipermail/devel/2014-March/196900.html
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
Moving to glibc, as this looks like an ldconfig bug.
The description in comment 10 would make sense as I have upgraded openldap between versions several times since this machine was installed.
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 libldap_r-2.4.so.2.10.2 libldap-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.
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!
Pushed: http://pkgs.fedoraproject.org/cgit/openldap.git/commit/?id=079ea99963aae4a3734547ab32da6374e27dab9c 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
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
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.
It seems to be working again now, try again.
*** Bug 1028553 has been marked as a duplicate of this bug. ***