Bug 348601
Summary: | move NSPR and NSS .so files from /usr/lib to /lib | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Karel Zak <kzak> |
Component: | nss | Assignee: | Kai Engert (:kaie) (inactive account) <kengert> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | caillon, pvrabec, rcritten, rrelyea, stransky, tmraz |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-07-08 04:46: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: | |||
Bug Blocks: | 348411, 434395 |
Description
Karel Zak
2007-10-23 10:51:02 UTC
I assume this means we must move all NSS dependencies, too, to /lib This includes NSPR I have a patch to both packages that moves the files. I built and installed locally, and I'm still able to run Firefox, even in FIPS mode, which means moving the .chk files to /lib was ok, too. The new listing of the packages is this: [kaie@intel:~]$ rpm -ql nspr /lib/libnspr4.so /lib/libplc4.so /lib/libplds4.so [kaie@intel:~]$ rpm -ql nss /etc/pki/nssdb /etc/pki/nssdb/cert8.db /etc/pki/nssdb/key3.db /etc/pki/nssdb/secmod.db /etc/prelink.conf.d/nss-prelink.conf /lib/libfreebl3.chk /lib/libfreebl3.so /lib/libnss3.so /lib/libnssckbi.so /lib/libnssdbm3.so /lib/libnsspem.so /lib/libsmime3.so /lib/libsoftokn3.chk /lib/libsoftokn3.so /lib/libssl3.so /usr/lib/nss /usr/lib/nss/unsupported-tools /usr/lib/nss/unsupported-tools/shlibsign I'm now testing to build mozilla, to verify the system libs are still found in that new location. Fixed in: nspr-4.6.99.2-2.fc9 nss-3.11.99.2b-3.fc9 I'm reopening, because there are issues, thanks to Rob for making me aware. NSS ships both .so files and .a files. Before this change, all such files were located in the same directory, /usr/lib. Now, after the change, we have the .so files in /lib and the .a files in /usr/lib. Which of the following should be done? (a) move all nss .a files to /lib (b) change nss-config and pkg-config to list both /lib and /usr/lib (c) ? Opinions? (c) - move only .so to /lib(64) and make symlink in /usr/lib(64) pointing to /lib(64), leave nss-config and pkg-config as is. I think this is the most correct way. which .a files? I'm starting to think we need multiple results from pkg-config. 1) applications that just use crypto & certificates (-lnss3 -lnss3util -lsoftoken3) 2) applications that just use ssl (-lssl3 -lnss3 -lnss3util -lsoftoken3 ) 3) applications that just use smime (-lsmime3 -lnss3 -lnss3util -lsoftoken3) 4) applications that all shared libraries (-lssl3 -lsmime3 -lnss3 -lnss3util -lsofotken3 ) 5) applications that use various nss .a files. Default would be 4). 5 would include both /lib and /usr/lib. 5 may be split up wrt which .a files are included. I don't think we want to include the nss .a files in /lib. bob Bob, Tomas, thanks a lot for your quick replies. (In reply to comment #5) > (c) - move only .so to /lib(64) and make symlink in /usr/lib(64) pointing to > /lib(64), leave nss-config and pkg-config as is. I like this proposal. I think you want that nss-config and pkg-config point to /usr/lib(64). (they currently point to /lib(64)) (In reply to comment #6) > which .a files? nss-devel has libcrmf.a and nss-pkcs11-devel has libnssb.a and libbssckfw.a > I'm starting to think we need multiple results from pkg-config. This sounds complicated. I think this proposal will not work as soon as you have an application that wants to link with both .so files and a .a file (like PSM). > I don't think we want to include the nss .a files in /lib. I agree. Bob, do you think Thomas's proposal is good? I found that "zlib" and "zlib-devel" already implement what Tomas proposes. $ rpm -ql zlib| grep -w so | xargs ls -ld lrwxrwxrwx 1 root root 13 13. Jan 04:50 /lib/libz.so.1 -> libz.so.1.2.3 -rwxr-xr-x 1 root root 74928 15. Aug 2007 /lib/libz.so.1.2.3 $ rpm -ql zlib-devel| grep -w so | xargs ls -ld lrwxrwxrwx 1 root root 23 13. Jan 04:51 /usr/lib/libz.so -> ../../lib/libz.so.1.2.3 > Bob, do you think Thomas's proposal is good? yes. > nss-devel has libcrmf.a The users of libcrmf.a are pretty small. It would be safe > nss-pkcs11-devel has libnssb.a and libbssckfw.a nss-pkcs11-devel should have it's own pkg-config. Applications that use these will not like with any of the NSS shared libraries. > This sounds complicated. > I think this proposal will not work as soon as you have an application that > wants to link with both .so files and a .a file (like PSM). I'm particularly interest in those packages that just need nss3 or just need ssl3/nss3. There is a hierarchy, so it's not as complicated as it sounds. For instance, all users of libcrmf.a would automatically need the rest of NSS (at least nss3 and smime3) anyway. In that case I would say 5) would be include all the libraries. If we included some of the libraries used for nss-tools, they should probably include their own pkg-config... bob (In reply to comment #7) > I like this proposal. > I think you want that nss-config and pkg-config point to /usr/lib(64). > (they currently point to /lib(64)) Of course. Adding Chris and Martin to make sure you're aware of this change in rawhide. If something goes wrong, please let me know. Ideally you won't notice the change. New packages: nss-3.11.99.4-1.fc9 nspr-4.7.0.99.1-1.fc9 I hope they are in the buildroot already, maybe it'll take another hour or so. Rob, could you please try if this works for you? 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 builds as of 2008-07-03, version 3.12.0.3-3.fc10. |