RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1297522 - Undefined python_provide causes silently missing provides
Summary: Undefined python_provide causes silently missing provides
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Orsava
QA Contact: Branislav Náter
URL:
Whiteboard:
: 1307190 (view as bug list)
Depends On:
Blocks: 1297585 1297586 1297587 1307190
TreeView+ depends on / blocked
 
Reported: 2016-01-11 18:52 UTC by Nathaniel McCallum
Modified: 2017-08-01 20:25 UTC (History)
9 users (show)

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
Clone Of:
Environment:
Last Closed: 2017-08-01 20:25:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1353934 0 unspecified CLOSED NT escaping in shebang in easy_install 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2017:1868 0 normal SHIPPED_LIVE Moderate: python security and bug fix update 2017-08-01 18:24:21 UTC

Internal Links: 1353934

Description Nathaniel McCallum 2016-01-11 18:52:11 UTC
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 18:10:14 UTC
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 16:51:23 UTC
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 17:02:17 UTC
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 12:39:38 UTC
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 13:02:39 UTC
*** Bug 1307190 has been marked as a duplicate of this bug. ***

Comment 11 Jan Pokorný [poki] 2017-03-23 19:04:09 UTC
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ý [poki] 2017-03-23 19:44:20 UTC
re [comment 11]: ...as long as python-setuptools package is involved.

Comment 13 Tomas Orsava 2017-03-24 11:04:36 UTC
(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 20:25:03 UTC
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.