Bug 518795 - nss-util-devel claims to provide nss-devel = 3.12.3.99.3-8 while not doing this and other troubles
Summary: nss-util-devel claims to provide nss-devel = 3.12.3.99.3-8 while not doing th...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nss-util
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Elio Maldonado Batiz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-22 22:36 UTC by Michal Jaegermann
Modified: 2010-09-28 16:03 UTC (History)
3 users (show)

Fixed In Version: nss-3.12.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-28 16:03:25 UTC


Attachments (Terms of Use)

Description Michal Jaegermann 2009-08-22 22:36:57 UTC
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

Comment 1 Elio Maldonado Batiz 2009-08-22 22:59:16 UTC
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.

Comment 2 Michal Jaegermann 2009-08-22 23:53:34 UTC
> 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).

Comment 3 Elio Maldonado Batiz 2009-08-23 00:29:23 UTC
(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.

Comment 4 Michal Jaegermann 2009-08-23 02:38:59 UTC
> 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.

Comment 5 Michal Jaegermann 2009-08-24 20:47:47 UTC
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

Comment 6 Elio Maldonado Batiz 2009-09-17 04:24:26 UTC
The chained build of nss, nss-softokn, and nss-util for 3.12.4-8 should address most reported problems.

Comment 7 Bug Zapper 2009-11-16 11:36:37 UTC
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


Note You need to log in before you can comment on or make changes to this bug.