This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1297522 - Undefined python_provide causes silently missing provides
Undefined python_provide causes silently missing provides
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Tomas Orsava
Branislav Náter
:
: 1307190 (view as bug list)
Depends On:
Blocks: 1297585 1297586 1297587 1307190
  Show dependency treegraph
 
Reported: 2016-01-11 13:52 EST by Nathaniel McCallum
Modified: 2017-08-01 16:25 EDT (History)
9 users (show)

See Also:
Fixed In Version: python-2.7.5-55.el7
Doc Type: Enhancement
Doc Text:
Feature: Python RPM macros were updated to be in sync with packaging macros in Fedora/EPEL, including the new %python_provide macro. Reason: To simplify packaging Python RPMs for RHEL and to allow easier conversion of Fedora/EPEL packages to RHEL packages. Result: You can now use Python and Python 2 macros available in [Fedora] and [EPEL]. [Fedora] https://fedoraproject.org/wiki/Packaging:Python [EPEL] https://fedoraproject.org/wiki/EPEL:Packaging#Python
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 16:25:03 EDT
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)

  None (edit)
Description Nathaniel McCallum 2016-01-11 13:52:11 EST
Fedora's packaging guidelines[1] for python packages suggests the use of the python_provide macro for python2 subpackages. Unfortunately, since this macro is missing in RHEL7, python2 subpackages silently lack the corresponding provide directive.

[1] https://fedoraproject.org/wiki/Packaging:Python
Comment 2 Orion Poplawski 2016-04-26 14:10:14 EDT
Note that this macro is defined in python-rpm-macros for EPEL7.  If this is added in RHEL7 we should be careful as to not conflict somehow.
Comment 3 Tomas Orsava 2017-03-21 12:51:23 EDT
As the request of a new RHEL component to house the Python macros was not approved in time for RHEL 7.4 and it doesn't look promising (BZ#1377737), we've decided to instead to update the Python RPM macros that are in the python-devel subpackage.
Comment 4 Tomas Orsava 2017-03-21 13:02:17 EDT
I'm planning to update the RHEL Python RPM macros to be in sync with their latest  version in EPEL7 which contains the %python_provide macro as well as other macros that should simplify packaging between Fedora/EPEL and RHEL.

(In reply to Orion Poplawski from comment #2)
> Note that this macro is defined in python-rpm-macros for EPEL7.  If this is
> added in RHEL7 we should be careful as to not conflict somehow.

I believe it should be fine:
1. The files don't conflict (EPEL installs into the /usr/lib/rpm/macros.d/ directory, whereas the RHEL Python macros are installed to /etc/rpm).
2. If the macro is defined twice it does not cause any issues.
3. The RHEL macro files take precedence, so we don't have to worry in case EPEL decides to switch the default for example.

Another possible issue is that the %{python3_pkgversion} and %{python3_other_pkgversion} macros used within the %{python_provide} macro are missing in RHEL. However, in their absence the lua code will run fine for Python 2 packages and will print an error only if invoked for Python 3 packages (unless the python-srpm-macros package from EPEL is installed). That is a desirable behaviour as RHEL without EPEL does not support building Python 3 packages.

I'll do some more testing to make sure.
Comment 5 Tomas Orsava 2017-03-22 08:39:38 EDT
Here is a reproducer to test that the macros are correctly installed and working:

1. Verify that output is NOT the same as input:

E.g.: $ rpm --eval "%py_build"
Wrong output:
%py_build

Correct output is anything else (which signifies that the macro is defined).

$ rpm --eval "%py_build"
$ rpm --eval "%py_build_egg"
$ rpm --eval "%py_build_wheel"
$ rpm --eval "%py2_build"
$ rpm --eval "%py2_build_egg"
$ rpm --eval "%py2_build_wheel"
$ rpm --eval "%py_install"
$ rpm --eval "%py_install_egg"
$ rpm --eval "%py_install_wheel"
$ rpm --eval "%py2_install"
$ rpm --eval "%py2_install_egg"
$ rpm --eval "%py2_install_wheel"



2. Verify exact output:

$ rpm --eval "%python_provide python-testsample"
Provides: python2-testsample = %{version}-%{release}



$ rpm --eval "%define buildarch noarch" --eval "%python_provide python2-testsample"


Provides: python-testsample = %{version}-%{release}
Obsoletes: python-testsample < %{version}-%{release}

(the two empty lines are expected)
Comment 6 Tomas Orsava 2017-03-22 09:02:39 EDT
*** Bug 1307190 has been marked as a duplicate of this bug. ***
Comment 11 Jan Pokorný 2017-03-23 15:04:09 EDT
I am afraid %py_build macro will be unusable unless %py2_shbang_opt
sub-macro undefined/overridden as empty, because of the unresolved
(WONTFIX) [bug 1353934].  It needs to be tested, though.
Comment 12 Jan Pokorný 2017-03-23 15:44:20 EDT
re [comment 11]: ...as long as python-setuptools package is involved.
Comment 13 Tomas Orsava 2017-03-24 07:04:36 EDT
(In reply to Jan Pokorný from comment #11)
> I am afraid %py_build macro will be unusable unless %py2_shbang_opt
> sub-macro undefined/overridden as empty, because of the unresolved
> (WONTFIX) [bug 1353934].  It needs to be tested, though.

As far as I understand, [bug 1353934] only manifests itself under certain circumstances and even then the macro won't be useless per se, it'll just set a wrong shebang. And there is a workaround for it that can be applied. I've tested a few packages and haven't run into the issue.

The macros are taken directly from EPEL7 and thus are tested, at least to an extent. The point of this exercise is to keep RHEL and EPEL packaging as close as possible, so I think it will be better to keep it as is.
Comment 16 errata-xmlrpc 2017-08-01 16:25:03 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:1868

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