Bug 239375
| Summary: | libssl installed in /lib but depends on libraries in /usr/lib | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Jackson <ajax> |
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | nalin, triage |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openssl-0.9.8j-10.fc11 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-04-21 09:32:39 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: | 240277 | ||
| Bug Blocks: | 446451 | ||
The question is - should openssl libs be moved to /usr/lib or Kerberos libs moved to /lib? Nalin, what do you think? Moving libz to /lib shouldn't be a problem as it is a really small library. Hmm, I'm not really a fan of moving Kerberos to /, but given that there are binaries in /sbin and /bin which require OpenSSL, I don't think we can move OpenSSL's libraries. Perhaps these binaries could require just libcrypto.so and not libssl.so. On almost full rawhide install: Binaries depending on libssl.so: /bin/rpm Binaries depending on libcrypto.so: /bin/rpm /sbin/dhcp6c /sbin/grubby /sbin/nash /sbin/setkey I suppose rpm case is due to linkage to libneon which is already in /usr/lib. Perhaps there should be 2 rpm binaries one without HTTP(S) support in /bin and one with it in /usr/bin? That's weird: rpm-4.4.2-46.fc7 on x86_64 doesn't have a dependency between /bin/rpm and either libssl or libcrypto, which suggests to me that there's only some link-time cleanup needed there. Attempting to relink "setkey" with "-Wl,-as-needed" added to setkey_LDFLAGS in the right Makefile.am removed both its libcrypto and Kerberos dependencies, so that might as easily fall out as well. My rawhide wasn't fully updated. The rpm libneon dependency was apparently recently dropped. So I propose to move libssl.so to /usr/lib and leave libcrypto in /lib. Nalin, do you think it can bring any problems that the openssl package would own some libraries in /usr/lib and some in /lib? I can think of just a little bit confusion to users but that shouldn't be a problem. I don't think it'll be a problem once nothing in /bin and /sbin depends on it. If we want to be serious about it, we should probably have a look at /lib and its subdirectories, too. I know we've got some modules for PAM which depend on libraries in /usr/lib. PAM is a different case. The /lib(64)/security path to modules is hardcoded into the PAM library and I don't think it is worth it to add another /usr/lib(64)/security directory to libpam as a search path. So there will always be modules in /lib(64)/security which depend on things in /usr. The basic modules contained in pam package itself don't and I think that's sufficient. Otherwise I completely agree - there are many other binaries and libraries in /bin /sbin and /lib linking to /usr/lib. Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Stupid bug zapper! Cannot you see that this bug blocks F10Target?? This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fixing version to align with rawhide again. Sorry for the noise. Fixed in F11 by moving libraries to /usr/lib{64,}/ as nothing in / depends on openssl anymore.
|
Description of problem: % ldd /lib/libssl.so.0.9.8b linux-gate.so.1 => (0x00827000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x04428000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00997000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x00976000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x04472000) libresolv.so.2 => /lib/libresolv.so.2 (0x00955000) libcrypto.so.6 => /lib/libcrypto.so.6 (0x00110000) libdl.so.2 => /lib/libdl.so.2 (0x00bd3000) libz.so.1 => /usr/lib/libz.so.1 (0x00bda000) libc.so.6 => /lib/libc.so.6 (0x00a53000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00a25000) /lib/ld-linux.so.2 (0x80000000) Version-Release number of selected component (if applicable): openssl-0.9.8b-12.fc7