Description of problem: Attempting to update the nss RPM fails because of a conflict with perl-PAR-Packer on /usr/share/man/man1/pp.1.gz. Version-Release number of selected component (if applicable): perl-PAR-Packer-1.014-2.fc19.x86_64 nss-tools-3.15.1-1.fc19.x86_64 How reproducible: Have already installed perl-PAR-Packer. Attempt to use "yum update" to update nss-tools-3.15-5.fc19.x86_64 to nss-tools-3.15.1-1.fc19.x86_64. Actual results: Transaction check error: file /usr/share/man/man1/pp.1.gz from install of nss-tools-3.15.1-1.fc19.x86_64 conflicts with file from package perl-PAR-Packer-1.014-2.fc19.x86_64 Expected results: Additional info: I'm reporting this bug against nss-tools because I perl-PAR-Packer installed first, but perhaps perl-PAR-Packer should be the RPM to be changed.
Indeed, perl-PAR-Packer should be changed to not try to install an empty man page for its pp tool! I got the latest f19 build from http://koji.fedoraproject.org/koji/buildinfo?buildID=391956 [emaldona@localhost ~]$ mkdir examine [emaldona@localhost ~]$ cd examine/ [emaldona@localhost examine]$ rpmdev-extract ~/Downloads/perl-PAR-Packer-1.014-2.fc19.x86_64.rpm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/bin/par.pl perl-PAR-Packer-1.014-2.fc19.x86_64/usr/bin/parl perl-PAR-Packer-1.014-2.fc19.x86_64/usr/bin/parldyn perl-PAR-Packer-1.014-2.fc19.x86_64/usr/bin/pp perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/doc/perl-PAR-Packer-1.014 perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/doc/perl-PAR-Packer-1.014/AUTHORS perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/doc/perl-PAR-Packer-1.014/ChangeLog perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/doc/perl-PAR-Packer-1.014/README perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/doc/perl-PAR-Packer-1.014/TODO perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man1/par.pl.1.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man1/parl.1.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man1/pp.1.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/App::Packer::PAR.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/Dynamic.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Filter.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Filter::Bleach.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Filter::Bytecode.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Filter::Obfuscate.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Filter::PatchContent.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Filter::PodStrip.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::Packer.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/PAR::StrippedPARL::Base.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/Static.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man3/pp.3pm.gz perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/App perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/App/Packer perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/App/Packer/PAR.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter/Bleach.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter/Bytecode.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter/Obfuscate.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter/PatchContent.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Filter/PodStrip.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/Packer.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/StrippedPARL perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/StrippedPARL/Base.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/StrippedPARL/Dynamic.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/PAR/StrippedPARL/Static.pm perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/perl5/vendor_perl/pp.pm [emaldona@localhost examine]$ ls -l perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man1/pp.1.gz -rw-r--r--. 1 emaldona emaldona 20 Feb 16 2013 perl-PAR-Packer-1.014-2.fc19.x86_64/usr/share/man/man1/pp.1.gz Notice that pp.1.gz is only one byte in size. I then examined the actual sources and pp.1 is empty. I there is no contents, perl-PAR-Packer trying to install that empty manpage.
The empty manpage is another issue and needs to be fixed. However, nss-tools' pp utility is new and not in standard path. If the author (you) ever decides to move it, we'll have another problem in */bin. The manpage conflict is just a consequence of this. The tool should be renamed.
We should be able to close this bug thanks to Ian Morgan who wrote a patch to perl-PAR-packer, see https://bugzilla.redhat.com/show_bug.cgi?id=1022558#c3
That's not a viable solution; nothing has changed about what I stated in comment #2.
OK, so the missing man page is a separate issue. That should be logged as a separate (documentation deficiency) bug and should not hold up fixing the packaging bug so that it can be installed. Right now, the package CANNOT be installed at all due to the conflict. My simple patch on bz#1022558 (https://bugzilla.redhat.com/attachment.cgi?id=919965) resolves that issue and allows the package to install. Without that, the package being in the repository at all is pointless, and I have to keep rolling my own with the patch just so that it can be installed (without --force and constant conflict warnings thereafter). One cannot make the choice to remove the conflicting nss-tools package because it is in a critical package dependency chain and therefore cannot be removed.
(In reply to Ian Morgan from comment #5) > OK, so the missing man page is a separate issue. That should be logged as a > separate (documentation deficiency) bug True. I'll file a report for that. > Right now, the package CANNOT be > installed at all due to the conflict. My simple patch on bz#1022558 > (https://bugzilla.redhat.com/attachment.cgi?id=919965) resolves that issue > and allows the package to install. Without that, the package being in the > repository at all is pointless, and I have to keep rolling my own with the > patch just so that it can be installed (without --force and constant > conflict warnings thereafter). > > One cannot make the choice to remove the conflicting nss-tools package > because it is in a critical package dependency chain and therefore cannot be > removed. This is true. However, instead of removing (albeit currently useless) PAR::Packer's manpage, you should really patch nss-tools. I'm not sure what to recommend there -- perhaps rename the manpage to nss-pp. Or move it out of MANPATH, given the command itself isn't readily available in most people's PATH anyway.
PAR::Packer's pp(1) manpage is empty https://bugzilla.redhat.com/show_bug.cgi?id=1163390
Elio, The man pages in nss-tools for pp.1.gz, vfychain.1.gz, and vfyserv.1.gz relate to programs in the /usr/lib64/nss/unsupported-tools/ directory, which is of course not in the standard path for most people. Per Petr's above comment, would you agree to move those three man pages out of /usr/share/man/man1/, and into something like /usr/share/doc/nss-tools/ ? Something's got to budge between these two packages.
(In reply to Petr Šabata from comment #2) > The empty manpage is another issue and needs to be fixed. I's highly related. I do have patch to install the nss-tools pp man page in the alternative location, /usr/share/doc/nss-tools/, Ian suggested on Comment 4. The problem is that there is no way to tell users of the new location. When someone tries man pp they will get an error beccause pp is emtpty and they will start yelling that we messed up the pp from nss-tools. Only a few folks know it is perl-PAR-Packer that that has and empty man pages. > > However, nss-tools' pp utility is new and not in standard path. If the > author (you) ever decides to move it, we'll have another problem in */bin. > The manpage conflict is just a consequence of this. > > The tool should be renamed. I have logged a bug with upstream nss suggesting as much but if we rename it may break scripts that depend on being named pp so it doesn't seem to be a a vable option.
(In reply to Ian Morgan from comment #8) > Elio, > > The man pages in nss-tools for pp.1.gz, vfychain.1.gz, and vfyserv.1.gz > relate to programs in the /usr/lib64/nss/unsupported-tools/ directory, which > is of course not in the standard path for most people. Only pp.1.gz is having a coflict as far I know. I haven't heard of any problems with the other two, > > Per Petr's above comment, would you agree to move those three man pages out > of /usr/share/man/man1/, and into something like /usr/share/doc/nss-tools/ ? Thate would be just pp. As already meantioned, I am considering it and it's prudent to consult with my temmates first. I'll attach the patch shortly. > > Something's got to budge between these two packages. For the moving to a new loaction to work without users screaming at me too much it would help a lot if pp manpage from PERL-PAR-Packer had some contents. I see that PAR-Packer has very good online documentation for pp the one at http://search.cpan.org/~rschupp/PAR-Packer-1.024/lib/PAR/Packer.pm is already in a manpage style. Would it be too hard to create man page based on this and submit it upstream? Petr, if you don't currely have the tome to a full fledged nmanpage, perhaps a minimal man page with a link to the upstream online page will suffice. In order to help we would need that man page (whether full or minimalist) to have a note stating that there is another tool named pp from nss and if that's what the user is looking for, then man /usr/share/doc/nss-tools/pp.1 is they await to get it. What do you think?
Created attachment 960493 [details] Relocates pp.1 to /usr/share/doc/nss-tools/pp.1
(In reply to Elio Maldonado Batiz from comment #9) > (In reply to Petr Šabata from comment #2) > > The empty manpage is another issue and needs to be fixed. > > I's highly related. I do have patch to install the nss-tools pp man page in > the alternative location, /usr/share/doc/nss-tools/, Ian suggested on > Comment 4. The problem is that there is no way to tell users of the new > location. When someone tries man pp they will get an error beccause pp is > emtpty and they will start yelling that we messed up the pp from nss-tools. > Only a few folks know it is perl-PAR-Packer that that has and empty man > pages. I could be wrong but I wouldn't expect people to complain about an `unsported' binary's manpage being moved. (In reply to Elio Maldonado Batiz from comment #10) > Only pp.1.gz is having a coflict as far I know. I haven't heard of any > problems with the other two, This is a matter of principle. If you move the docs for only one of these tools, it will be confusing and inconsistent. > For the moving to a new loaction to work without users screaming at me too > much it would help a lot if pp manpage from PERL-PAR-Packer had some > contents. I see that PAR-Packer has very good online documentation for pp > the one at http://search.cpan.org/~rschupp/PAR-Packer-1.024/lib/PAR/Packer.pm > is already in a manpage style. > > Would it be too hard to create man page based on this and submit it > upstream? > > Petr, if you don't currely have the tome to a full fledged nmanpage, perhaps > a minimal man page with a link to the upstream online page will suffice. In > order to help we would need that man page (whether full or minimalist) to > have a note stating that there is another tool named pp from nss and if > that's what the user is looking for, then man /usr/share/doc/nss-tools/pp.1 > is they await to get it. What do you think? I filed bug 1163390 the other day; I plan to get it in near future. There's a number of options listed in the code which I plan to put there.
(In reply to Petr Šabata from comment #12) > I could be wrong but I wouldn't expect people to complain about an `unsported' >binary's manpage being moved. You would be surprised. Some of those so called "unsupported" tools are quite popular, useful when folks file bugs and need to provide us extra information, and we actually actively maintain them. When the man pages effort started the plan was for the supported ones only but several users requested that a subset of the "unsupported" ones be documented as well. > This is a matter of principle. If you move the docs for only one of these > tools, it will be confusing and inconsistent. I see your point, but I'll rather do it to the one causing conflicts. > I filed bug 1163390 the other day; I plan to get it in near future. There's > a number of options listed in the code which I plan to put there. Thank you for that.
*** Bug 1169648 has been marked as a duplicate of this bug. ***
Just FYI, I "added" the manpage (turns the content was there all along, just not in the right place) yesterday.
Comment on attachment 960493 [details] Relocates pp.1 to /usr/share/doc/nss-tools/pp.1 A bit of explanation is in order regarding the contitionalization. On RHEL the perl_PAR-Packer package is not available so it is not a problem there. I originally had %if %{defined fedora} everywhere and that didn't work. Contrary to what the documentation states fedora is actually defined for rhel. See http://fedoraproject.org/wiki/Packaging:DistTag I must test for %if %{defined rhel} ... %else ... %endif throughout. The RHEL nss.spec doesn't need to be changed but I'm doing this as a proteccaution. Two years from now when they start working on RHEL-8 the Red Hat release engieening folks will do an automatic merge from fedora and we don't want nasty susprises when this bug will have faded from our minds. This patch is not quite correct. The test to decide whether top create the docs directory is based on testing for fedora and it should have been based on rhel like in the other conditionals.
Created attachment 964752 [details] nss.spec changes to install pp man page in alternative location
Comment on attachment 964752 [details] nss.spec changes to install pp man page in alternative location Tested on Fedora, RHEL-7, and CentOS-7 and only on Fedora is the alternative location used.
Thanks, Elio. I would still suggest moving manpages for all the %{_libdir}nss/unsupported-tools to the doc directory. This would be more consistent plus people who use these tools could just set their MANPATH to /usr/share/doc/nss/man and work as always, without guessing what is where. Also, doing this for EL as well would, while not needed at the moment, prevent possible future conflicts, either in RHEL/CentOS directly or from EPEL. And one more thing: consider using %{_datadir} instead of /usr/share.
Created attachment 969321 [details] spec file changes to install pp man page in alternative location Incorporated suggestions by Petr and Kamil.
Comment on attachment 969321 [details] spec file changes to install pp man page in alternative location Looks much better now. Please also use %%{_mandir} instead of %{_mandir} in the change log entry to prevent it from expanding to a nonsense statement: $ rpm -pq ./nss-3.17.3-2.fc20.src.rpm --changelog | head -4 * Mon Dec 15 2014 Elio Maldonado <emaldona> - 3.17.3-2 - Resolves: Bug 987189 - nss-tools RPM conflicts with perl-PAR-Packer - Install pp man page in /usr/share/doc/nss-tools/pp.1 - Use /usr/share/man instead of /usr/share/man as more generic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
nss-3.17.3-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/nss-3.17.3-2.fc21
nss-3.17.3-1.fc20, nss-util-3.17.3-1.fc20, nss-softokn-3.17.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2014-16530/nss-util-3.17.3-1.fc20,nss-3.17.3-1.fc20,nss-softokn-3.17.3-1.fc20
nss-3.17.3-2.fc19, nss-util-3.17.3-1.fc19, nss-softokn-3.17.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2014-16826/nss-3.17.3-2.fc19,nss-util-3.17.3-1.fc19,nss-softokn-3.17.3-1.fc19
Thank you!
Package nss-3.17.3-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nss-3.17.3-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-17085/nss-3.17.3-2.fc21 then log in and leave karma (feedback).
(In reply to Fedora Update System from comment #26) > Package nss-3.17.3-2.fc21: > * should fix your issue, > * was pushed to the Fedora 21 testing repository, > * should be available at your local mirror within two days. > Update it with: > # su -c 'yum update --enablerepo=updates-testing nss-3.17.3-2.fc21' > as soon as you are able to. > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2014-17085/nss-3.17.3-2.fc21 > then log in and leave karma (feedback). Could someone please leave karma to this one? I want to make sure the f21 one goes to stable before the f20 one does. This is to prevent problems later on if someone tries to update their f20 system to f21 as nss has the same nvr. Thanks in advance. -Elio
nss-3.17.3-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.17.3-2.fc20, nss-util-3.17.3-1.fc20, nss-softokn-3.17.3-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.