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.

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.

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.

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)

*** Bug 1307190 has been marked as a duplicate of this bug. ***

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.

re [comment 11]: ...as long as python-setuptools package is involved.

(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.

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