Description of problem: The spec contains %{?python_provide:%python_provide python2-%{srcname}} but does not define srcname Version-Release number of selected component (if applicable): 0.3.3-6 see also bug 1337559
pdf-stapler has broken dependencies in the rawhide tree: On x86_64: pdf-stapler-0.3.3-6.fc24.noarch requires python-PyPDF2 On i386: pdf-stapler-0.3.3-6.fc24.noarch requires python-PyPDF2 On armhfp: pdf-stapler-0.3.3-6.fc24.noarch requires python-PyPDF2 Please resolve this as soon as possible. We tried to fix that in bug #1337559, but does not work for unknown reasons. Generally, it's better for pdf-stapler to BR: python2-PyPDF2 anyways.
(In reply to Raphael Groner from comment #1) > We tried to fix that in bug #1337559, but does not work for unknown reasons. > Generally, it's better for pdf-stapler to BR: python2-PyPDF2 anyways. This bug is about pdf-stapler containing the same bug as python-PyPDF2 initially btw. Therefore this BR: python2-PyPDF2 does not help to fix this bug. And just to make sure it is known: The best solution would be to port pdf-stapler to python3 to fix bug 1337559 but still this bug needs a fix in the pdf-stapler spec file.
(In reply to Raphael Groner from comment #1) > We tried to fix that in bug #1337559, but does not work for unknown reasons. > Generally, it's better for pdf-stapler to BR: python2-PyPDF2 anyways. FYI: python-PyPDF2 was not yet updated in Rawhide, therefore it was not fixed there, but afaics it should be fixed with the next Rawhide push.
%python_provide was explicitly requested in the package review: https://bugzilla.redhat.com/show_bug.cgi?id=1234210#c37 IMHO this line can be removed. Our guidelines want it for any subpackage only and stapler neither has subpackages nor is it a library for general usage. When we (or upstream) decide to port to python3, this application moves as a whole to python3. No need to keep compatibility between python2 and 3. https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro What do you think?
Created attachment 1164456 [details] Split staplelib as module into a subpackage
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
(In reply to Raphael Groner from comment #4) > %python_provide was explicitly requested in the package review: > https://bugzilla.redhat.com/show_bug.cgi?id=1234210#c37 > > IMHO this line can be removed. Our guidelines want it for any subpackage > only and stapler neither has subpackages nor is it a library for general > usage. When we (or upstream) decide to port to python3, this application > moves as a whole to python3. No need to keep compatibility between python2 > and 3. > https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro > > What do you think? I am okay with removing this line. Let us do so and see if we can fix and close this bug.
There is no reason to remove this line. The guidelines say that python_provide should be used, and there's no significant reason to stray from that here. It would be better to either: 1. change %{?python_provide:%python_provide python2-%{srcname}} to %{?python_provide:%python_provide python2-staplelib} or 2. apply the patch comment #c5.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8) > There is no reason to remove this line. The guidelines say that > python_provide should be used, and there's no significant reason to stray > from that here. > It would be better to either: > 1. change %{?python_provide:%python_provide python2-%{srcname}} to > %{?python_provide:%python_provide python2-staplelib} > or > 2. apply the patch comment #c5. Is there a compelling reason for #2? #1 seems simpler, though I must confess that I do not know the intricacies of the two options.
#2 assume that pdf-stapler will move to python3 by default at some point, and that you'll want to keep the python2 version of the library around. If that's true (or at least likely), this patch will save you some work in the future. If not, #1 is probably better.
OK, let us go with the patch then. Perhaps Ralph wants to take this forward? I don't quite know what to do with this. Btw, there has been talk upstream (on github) about the fact that more-itertools has not been packaged for fedora. So i have put together a Fedora package https://bugzilla.redhat.com/show_bug.cgi?id=1381029 in case wanted to provide feedback.
pdf-stapler-0.3.3-8.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8ed6f3b95
pdf-stapler-0.3.3-8.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-67faa301bd
pdf-stapler-0.3.3-8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c3b2e1c00e
pdf-stapler-0.3.3-8.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
pdf-stapler-0.3.3-8.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
pdf-stapler-0.3.3-8.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.