Description of problem: Attempting to build new rawhide packages in koji appears to be blocked by a file conflict between nss-util and nss. Looks like nss needs to be updated to reflect the new nss-utils slpit out? Version-Release number of selected component (if applicable): * OLD - nss-util-3.12.3.99.3-8.fc12.i686.rpm * NEW - nss-util-3.12.3.99.3-8.1.fc12.i686.rpm * nss-3.12.3.99.3-7.1.fc12.i686 How reproducible: Steps to Reproduce: 1. Attempt a build of the 'abrt' package in rawhide using koji Actual results: DEBUG util.py:256: Transaction Check Error: DEBUG util.py:256: file /lib/libnssutil3.so from install of nss-util-3.12.3.99.3-8.1.fc12.i686 conflicts with file from package nss-3.12.3.99.3-7.1.fc12.i686 * See koji root.log - http://koji.fedoraproject.org/koji/getfile?taskID=1617414&name=root.log
DEBUG util.py:256: file /lib/libnssutil3.so from install of nss-util-3.12.3.99.3-8.1.fc12.i686 conflicts with file from package nss-3.12.3.99.3-7.1.fc12.i686. The nss-util install is trying to install libnssutil3 but that file is currently installed in the system as belonging to nss. This caused by my attempts to split off nss-softokn and nssutil from nss as their own packages. See bugs 508479 plus 515034 and 516032 for some background. Koji built nss-util without problem but as soon as it tried to build nss-softokn this conflict is reported as nss-softokn requires nss-util. The two new packages now own some of the libraries that formerly where owned by nss alone. I have consulted https://fedoraproject.org/wiki/Packaging:Conflicts among other sources and I am still at a loss on how to solve this.
I guess it simply can't work to have only portions of the new solution in cvs. I think it would have been better to do you all your testing locally, and only after you have a complete solution of all {nss,nss-util,nss-softokn} that can coexist, then it's time to add it to cvs. But I wonder, what causes the build environment to pull in the nss-util package? Is there any package already depends on nss-util explicitly? Or is that automatic behavior that pulls in any package that provides the resulting libnssutil3.so file? If you don't have a solution and want to avoid the conflict, I propose you change fedora cvs so that the nss-util package is completely empty, until you have the complete solution.
My fault, for not being sufficiently thorough in testing in a really clean environment and running rpmlint on every rpm file. The only way is to test all three packages together. nss-softoken depends on nss-util and that brings it in to be installed. It may happen indirectly with other packages. I agree to make the nss-util empty in CVS so I unblock others and have some time to investigate further.
If we think of this conflict as fitting into the Library Name Conflicts section in the document quoted, it is suggested to: Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/. I will experiment with this approach a bit, it's messy and I wish there was a cleaner way. Any ideas?
Installing: nss-util-devel x86_64 3.12.3.99.3-8.1.fc12 rawhide 50 k replacing nss-devel.x86_64 3.12.3.99.3-7.1.fc12 Installing for dependencies: nss-util x86_64 3.12.3.99.3-8.1.fc12 rawhide 86 k nss-devel causes nss-util-devel to be pulled in, which pulls in nss-util, which conflicts with nss.
The following remedial actions have been taken. nss-util has been untagged so it won't be built. I commented out most of the lines in nss-softokn.spec. It only produces an srpm but an empty binary rpm, no devel and the rpm will contain no libraries. Hope this is enough and no untagging may be necessary, not sure. I reverted nss to the state of the last stable build. I hope this will keep us going until I find a solution to the conflicts.
One of problems seems to be that nss-util-devel-3.12.3.99.3-8.1.fc12 obsoletes nss-devel < 3.12.3.99.3-8 despite of this small detail that the former does not seem to be even close to a replacement for the later; so "provides" appears out of the question. Now it is enough to have installed one package with a dependency on nss-devel, say rpm-devel, and we are for a ride. Missing bunch of libraries adds to the fun.
Oh, and there is another packaging "gotcha". All files in /usr/include/nss3/ are supplied by _both_ nss-util and nss-util-devel packages. They are the same, so you will not see conflicts, but this looks tad excessive. Currently all these are owned by nss-devel but there is also 52 more headers there not in nss-util-devel.
(In reply to comment #8) Hmm, headers should be supplied to the nss-{new-package}-devel package only where new-pakage would be with util or softokn. Yes, the other headers some would be supplied by nss-softokn and the rest by nss (what's left after splitting off nss-util and nss-softokn). Regarding comment #8, obsoletes is frown upon and it only partially replaces the original. Had we used capabilities in the monolithic nss that may have helped some. Kai had a long chat and brainstormed about how to solve the conflicts. One is never sure the think will work unless all three packages are tested in concert. The new packages that ow try to be the owners of some files, libraries and headers, will have conflict with the older nss (pre-split) that's running on the system on which we are trying to install. One would think that introducing what appears to be a circular dependency, the new packages requiring somehow the new nss, would solve the problem but that not feasible as we would have to get rid of the old one and bring part of the new one somehow. Unfortunately mock calls yum and rpm and they depend on nss. The chicken and egg problem. This is a very risky undertaking and hard to test in a comprehensive way with all the pieces in place using mock locally or with koji scratch builds before all sources are checked in. I had originally proposed a plan B which is to make nss-util and nss-softokn mere sub-packages of nss just like Kai did with nss-softokn-freebl. It doesn't offer the same level of simplicity of maintenance that we want to achieve for RHEL but is less risky and more and there is a greater chance that I could make it work on time for fedora 12 alpha.
Plan B does not solve the basic conflict problem. You still need nss-util packages. I believe you need to have the correct obsoletes to make this work.
> Regarding comment #8, obsoletes is frown upon ... I am not trying to say that obsoletes should be used; only that if you will type 'rpm -qp --obsoletes nss-util-devel-3.12.3.99.3-8.1.fc12.x86_64.rpm' then this responds with 'nss-devel < 3.12.3.99.3-8'. That means that yum attempts, as a part of the whole transaction, to remove nss-devel and and wondrous things start happening (that includes bringing in glibc.i686, which was not there up to now, and other packages too). Eventually the whole transaction falls apart - and that is a good thing in the context. It looks to me that if you want to move _parts_ of nss packages to corresponding nss-util packages then you need to update/install all these in one go or there will be conflicts; only something needs suitable "Requires" to make sure that the right updates will happen.
Obsoletes: nss < %{nss_split_version} would be equivalent to Requires: nss >= %{nss_split_version} I assume or is it stronger? Yes, it seems that the transaction must involve all three nss, softokn, and util all at once. Hard to pretest locally before committing the changes to CVS. Getting back to the transaction and assuming I got the right obsoletes we would we replacing nss on-the-fly underneath Mock which depends on nss indirectly at least via yum and rpm as far as I can tell. It does sound scary!
> Obsoletes: nss < %{nss_split_version} would be equivalent to > Requires: nss >= %{nss_split_version} I assume ... Eh? It does not look to me equivalent at all. AFAICS the first means "we want to dump nss if its version is small enough" while the second "do no install this is a suitable nss package is not available". Quite a different thing and a fixed, but high enough, version could be sufficient in the second case. Only then installing %{nss_split} pulls in nss too. I am possibly missing a bigger picture what this split is supposed to buy.
(In reply to comment #13) > I am possibly missing a bigger picture what this split is supposed to buy. It allows us to ship nss-softoken independently of the rest of nss. This is important to sites that need to keep nss-softoken at the current version that received FIPS validation while continuing to upgrade the rest of nss.
The problem has been solved. No need to rely on obsoletes. By following a subpackage approach (for nss-util and nss-softokn) first the system was bootstrapped and we could afterwards proceed to the actual split without conflicts.
should this get closed?
Yes, it should be closed. Probably I should not not be the one to do it. A way to verify the fix is to install Fedora 12 Alpha preferably from the Live CD image where you don't get the very latest and nss would be at the version prior to the split which was nss-util-3.12.3.99.3-6.fc12. Alternatively the DVD image but refrain from including the repo. Then do a yum update and there should be no conflicts nor any warning messages.