Description of problem: After updating the the current rawhide yum removes nss-devel and replaces it with nss-util-devel. It should do so because one can see this: $ rpm -q nss-util-devel --provides nss-devel = 3.12.3.99.3-8 pkgconfig(nss-util) = 3.12.3.99.3 nss-util-devel = 3.12.3.99.3-9.fc12 nss-util-devel(x86-64) = 3.12.3.99.3-9.fc12 Both first two claims are blatantly incorrect as nss-devel supplies a long list of headers and libraries which are NOT provided by nss-utils-devel and contents of /usr/lib64/pkgconfig/nss-util.pc and /usr/lib64/pkgconfig/nss.pc are quite different. OTOH headers and libraries from nss-util-devel are present in nss-devel. What is more nss-devel-3.12.3.99.3-10.fc12 does exist in the current rawhide and after an update above one can do 'yum install nss-devel' and that command runs without any problems and restores what was removed. Moreover _all_ header files from nss-util-devel are provided by nss-util too and libnssutil3.so also does "double dipping". As a result one now gets $ rpm -qf /usr/include/nss3/pkcs11.h nss-util-3.12.3.99.3-9.fc12.x86_64 nss-util-devel-3.12.3.99.3-9.fc12.x86_64 nss-devel-3.12.3.99.3-10.fc12.x86_64 and the same for any other header (plus /usr/include/nss3 directory) on nss-util-devel list. It appears that at this moment the only reasonable way out of this mess would be: a) nss-util has only /%{_lib}/libnssutil3.so on its file list b) nss-util-devel supplies only /usr/bin/nss-util-config and /usr/%{_lib}/pkgconfig/nss-util.pc and ... c) nss-util-devel requires nss-util BTW - 'rpm -q nss-util-devel --obsoletes' gives 'nss-devel < 3.12.3.99.3-8'. That is superflous with an incorrect "provides nss-devel" with a version high enough. Version-Release number of selected component (if applicable): nss-util-devel-3.12.3.99.3-9.fc12 How reproducible: Just try 'yum update nss*' with the current rawhide
Yes, "double-dipping" is something to address as I work on a new way of doing the split. The package nss-util has been untagged by release engineering but its is still around causing the problems that you point out. As I investigate a solution for this I am suffering through this as I use my rawhide systems for testing. Release Engineering, we need a way to prevent the nss-util package from appearing when users are doing updates or when updates are triggered automatically.
> The package nss-util has been untagged ... One issue I see with that is that every compilation which was using headers from nss-devel, and which are not in nss-util-devel, will fail. Is such breakage intentional? The same goes for missing libraries which nss-utils does not provide. Finding programs which would depend on those should be simple (start with 'rpm' although I did not check if it really falls apart).
(In reply to comment #2) > > The package nss-util has been untagged ... > > One issue I see with that is that every compilation which was using headers > from nss-devel, and which are not in nss-util-devel, will fail. Is such > breakage intentional? No, now nss-util-devel will provide it's own sunset of what nss-devel provides and the are installed in the same location so applications would tell the difference. The same goes for nss-softokn-devel. > > The same goes for missing libraries which nss-utils does not provide. Finding > programs which would depend on those should be simple (start with 'rpm' > although > I did not check if it really falls apart). Yes, nss-util-devel and nss-softokn-devel will provide their share of the libraries that currently nss-devel provides. You said BTW - 'rpm -q nss-util-devel --obsoletes' gives 'nss-devel < 3.12.3.99.3-8'. That is superflous with an incorrect "provides nss-devel" with a version high enough. I agree, Obsoletes was not the way to go. How can nss-util-devel obsolete nss-devel when it only provides a subset of the nss capabilities. You need all three. I am glad you mention provides I have been giving it some though and it may have the semantics we need. I am actually trying it out and its reducing the number of conflicts (there are more you have seen as I am doing softokn also). My local testing as well in a VM feeding the rpms from scratch build is giving me better results but I still have more to do. Thank you for your comments.
> No, now nss-util-devel will provide it's own sunset of what nss-devel provides I guess s/sunset/subset/? Correct? At least for now "subset" seems to an operational word and if nss is gone and you are trying to compile/use something which relies on parts which are missing than this will be not good enough. From where you will get, say, secpkcs7.h and a long list of others? OTOH I do not know how this is eventually supposed to look like. Surely now this is a mess. If you really plan to drop all "old nss" packages then why not to do replacements in one swoop? How otherwise in the future you are going to run an update from, say, F10 to F12? Messing with devel packages only looks like a sure recipe for a trouble.
This is surely much saner with 3.12.3.99.3-11.fc12 packages. There is still in bunch of files or directories claimed by muliple packages. In particular /etc/prelink.conf.d is owned by 'prelink' and 'nss-softokn-3.12.3.99.3-11.fc12' while you would want the later to own only /etc/prelink.conf.d/nss-prelink.conf. There is also a bunch of overlaps between 'nss-devel' and 'nss-util-devel' and between 'nss-devel' and 'nss-softokn-devel'. Here is a quick test for such overlaps with quite obvious indicators in output: rpm -ql nss-devel | while read n ; do echo -n "$n "; rpm -qf $n ; done and similar for other packages. If there are only two "owners" then you may pipe that through "grep -v '^/' -B1" for even better readability. With 3.12.3.99.3-11.fc12 that gives for 'nss-devel': /usr/include/nss3/nsslowhash.h nss-softokn-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 -- /usr/include/nss3/secoid.h nss-util-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 /usr/include/nss3/secoidt.h nss-util-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 -- /usr/include/nss3/secport.h nss-util-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 -- /usr/lib64/libfreebl3.chk nss-softokn-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 /usr/lib64/libfreebl3.so nss-softokn-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 -- /usr/lib64/libnssdbm3.so nss-softokn-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 -- /usr/lib64/libsoftokn3.chk nss-softokn-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64 /usr/lib64/libsoftokn3.so nss-softokn-devel-3.12.3.99.3-11.fc12.x86_64 nss-devel-3.12.3.99.3-11.fc12.x86_64
The chained build of nss, nss-softokn, and nss-util for 3.12.4-8 should address most reported problems.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping