I suggest that we stop distributing the NSS module libnssckbi.so. In past Fedora releases, we have effectively disabled the use of the libnssckbi.so module that is distributed by the NSS library project. Fedora contains the p11-kit-trust.so module (p11-kit-trust.rpm), which is now an essential system component. It's a binary compatible replacement for libnssckbi.so, made available trough the updates-alternatives system. Because p11-kit-trust has become an essential system component (and cannot be removed without removing e.g. dnf), the nss/libnssckbi.so module is no longer used by most applications. NSS should be changed to depend on p11-kit-trust. This should be a very low risk change, limited to the nss package, and most likely shouldn't affect other applications or packages.
Created attachment 1317144 [details] patch v1
rawhide fix: http://pkgs.fedoraproject.org/rpms/nss/c/61169569b13845986b3aeed3cfc3a3012a4427f3?branch=master
mod_nss-1.0.14-5 still requires it, but p11-kit-trust do not provides it (as seen in header), and not have correct update tool. It may be better to use in-package symlink, not script? error: Failed dependencies: /usr/lib64/libnssckbi.so is needed by (installed) mod_nss-1.0.14-5.fc27.x86_64
/usr/lib64/libnssckbi.so will continue to exist. It has been a symlink for several versions already, and points to /etc/alternatives/libnssckbi.so.x86_64 This has already been pointing by default to /usr/lib64/pkcs11/p11-kit-trust.so and will continue to do so. The equivalent can be said for the 32-bit version /usr/lib/libnssckbi.so which will be provided by p11-kit-trust.i686 The change requested in this bug is to shop shipping /usr/lib/nss/libnssckbi.so which was an optional, lower priority alternative (and essentially no longer be used, unless anyone tried to access it directly).
> /usr/lib64/libnssckbi.so will continue to exist But it not "officialy provided" by the p11-kit-trust. So, if someone try to update nss, dnf/rpm gives error message: Problem: problem with installed package mod_nss-1.0.14-5.fc27.x86_64 - package mod_nss-1.0.14-5.fc27.x86_64 requires /usr/lib64/libnssckbi.so, but none of the providers can be installed - cannot install both nss-3.32.0-3.fc28.x86_64 and nss-3.32.0-2.fc27.x86_64 - cannot install the best update candidate for package nss-3.32.0-2.fc27.x86_64 error: Failed dependencies: /usr/lib64/libnssckbi.so is needed by (installed) mod_nss-1.0.14-5.fc27.x86_64 So, I see 2 way: 0: manualy provide /usr/lib64/libnssckbi.so by p11-kit-trust, better with direct symlink. 1: rebuild mod_nss w/o reqirement - if possible.
(In reply to Anton Guda from comment #5) > > /usr/lib64/libnssckbi.so will continue to exist > But it not "officialy provided" by the p11-kit-trust. It's actually officially provided. The installation scripts of p11-kit install it. See http://pkgs.fedoraproject.org/rpms/p11-kit/blob/master/f/p11-kit.spec#_86 > So, if someone try to update nss, dnf/rpm gives error message: > > Problem: problem with installed package mod_nss-1.0.14-5.fc27.x86_64 > - package mod_nss-1.0.14-5.fc27.x86_64 requires /usr/lib64/libnssckbi.so, > but none of the providers can be installed > - cannot install both nss-3.32.0-3.fc28.x86_64 and nss-3.32.0-2.fc27.x86_64 > - cannot install the best update candidate for package > nss-3.32.0-2.fc27.x86_64 I don't understand how you were able to get into this state, can you please describe what you did? It seems the error message was shown because you tried to install both fc28 and fc27 packages in parallel? Here is a f27 scratch build from yesterday: https://koji.fedoraproject.org/koji/taskinfo?taskID=20725695
(In reply to Kai Engert (:kaie) from comment #6) > It's actually officially provided. > The installation scripts of p11-kit install it. > > See > http://pkgs.fedoraproject.org/rpms/p11-kit/blob/master/f/p11-kit.spec#_86 If the file is created in the %post scriptlet, it will exist on the file system but it does not automatically mean that the dependency resolver(s) will see it. The package that provides it (p11-kit-trust?) either needs to provide a %ghost (the one you have removed from the nss package) or there needs to be an explicit Provides tag. > I don't understand how you were able to get into this state, can you please > describe what you did? I can easily reproduce it on my up2date rawhide VM, too: % sudo dnf install mod_nss Last metadata expiration check: 0:02:26 ago on Fri 25 Aug 2017 06:44:42 PM CEST. Error: Problem: conflicting requests - nothing provides /usr/lib64/libnssckbi.so needed by mod_nss-1.0.14-5.fc27.x86_64
Thanks Kamil, that's helpful. Previously the NSS package had the %ghost entry. We should update p11-kit to add it.
I've filed 1485450 to handle the dependency regression, a scratch build is running, link in that bug.
I see the fix is in rawhide and F28 (in both nss and p11-kit packages), but not in F27. Kai, do you think we should do that as well in F27 or target F28+ only?
I think it's sufficient to garget F28+ only. I believe, at the time I had suggested this change, we were already past the change deadline for systemwide f27 changes. Unless there's a good reason to change f27, I'd keep it as is, to avoid surprises.
+1 for F28+ only. I may need to tweak mod_nss to handle this as well as it currently symlinks libnssckbi.so to ensure the roots are available.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.