Bug 987189 - nss-tools RPM conflicts with perl-PAR-Packer
nss-tools RPM conflicts with perl-PAR-Packer
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
19
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Elio Maldonado Batiz
Fedora Extras Quality Assurance
:
: 1169648 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-22 18:27 EDT by David Hull
Modified: 2015-01-07 18:54 EST (History)
13 users (show)

See Also:
Fixed In Version: nss-3.17.3-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-25 00:35:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Relocates pp.1 to /usr/share/doc/nss-tools/pp.1 (2.48 KB, patch)
2014-11-23 14:14 EST, Elio Maldonado Batiz
no flags Details | Diff
nss.spec changes to install pp man page in alternative location (2.59 KB, patch)
2014-12-04 11:38 EST, Elio Maldonado Batiz
no flags Details | Diff
spec file changes to install pp man page in alternative location (5.47 KB, patch)
2014-12-15 17:16 EST, Elio Maldonado Batiz
kdudka: review+
Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 915400 None None None Never

  None (edit)
Description David Hull 2013-07-22 18:27:21 EDT
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.
Comment 1 Elio Maldonado Batiz 2013-08-26 10:36:00 EDT
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.
Comment 2 Petr Šabata 2013-08-27 12:00:11 EDT
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.
Comment 3 Elio Maldonado Batiz 2014-07-22 13:23:36 EDT
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
Comment 4 Petr Šabata 2014-07-24 09:33:41 EDT
That's not a viable solution; nothing has changed about what I stated in comment #2.
Comment 5 Ian Morgan 2014-11-12 08:57:44 EST
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.
Comment 6 Petr Šabata 2014-11-12 10:29:59 EST
(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.
Comment 7 Petr Šabata 2014-11-12 10:37:53 EST
PAR::Packer's pp(1) manpage is empty
https://bugzilla.redhat.com/show_bug.cgi?id=1163390
Comment 8 Ian Morgan 2014-11-12 10:40:13 EST
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.
Comment 9 Elio Maldonado Batiz 2014-11-23 13:42:52 EST
(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.
Comment 10 Elio Maldonado Batiz 2014-11-23 14:06:17 EST
(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?
Comment 11 Elio Maldonado Batiz 2014-11-23 14:14:09 EST
Created attachment 960493 [details]
Relocates pp.1 to /usr/share/doc/nss-tools/pp.1
Comment 12 Petr Šabata 2014-11-24 11:40:38 EST
(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.
Comment 13 Elio Maldonado Batiz 2014-11-24 12:08:28 EST
(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.
Comment 14 Petr Šabata 2014-12-02 04:19:44 EST
*** Bug 1169648 has been marked as a duplicate of this bug. ***
Comment 15 Petr Šabata 2014-12-02 04:21:21 EST
Just FYI, I "added" the manpage (turns the content was there all along, just not in the right place) yesterday.
Comment 16 Elio Maldonado Batiz 2014-12-04 11:20:01 EST
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.
Comment 17 Elio Maldonado Batiz 2014-12-04 11:38:53 EST
Created attachment 964752 [details]
nss.spec changes to install pp man page in alternative location
Comment 18 Elio Maldonado Batiz 2014-12-04 11:44:07 EST
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.
Comment 19 Petr Šabata 2014-12-05 04:54:52 EST
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.
Comment 20 Elio Maldonado Batiz 2014-12-15 17:16:37 EST
Created attachment 969321 [details]
spec file changes to install pp man page in alternative location

Incorporated suggestions by Petr and Kamil.
Comment 21 Kamil Dudka 2014-12-16 09:45:48 EST
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@redhat.com> - 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
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Comment 22 Fedora Update System 2014-12-16 19:10:05 EST
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
Comment 23 Fedora Update System 2014-12-16 19:55:59 EST
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
Comment 24 Fedora Update System 2014-12-16 20:04:49 EST
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
Comment 25 Petr Šabata 2014-12-17 08:26:02 EST
Thank you!
Comment 26 Fedora Update System 2014-12-18 01:02:03 EST
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).
Comment 27 Elio Maldonado Batiz 2014-12-23 12:10:00 EST
 (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
Comment 28 Fedora Update System 2014-12-25 00:35:06 EST
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.
Comment 29 Fedora Update System 2015-01-07 18:54:46 EST
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.

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