Bug 1336097 - Update the package on EPEL-7 (especially because of %python_provide macro)
Summary: Update the package on EPEL-7 (especially because of %python_provide macro)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: python-rpm-macros
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-14 06:52 UTC by Matěj Cepl
Modified: 2019-11-09 01:07 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-15 14:43:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
example SPEC file (5.67 KB, text/plain)
2016-05-15 05:57 UTC, Matěj Cepl
no flags Details

Description Matěj Cepl 2016-05-14 06:52:20 UTC
Description of problem:
With %python-provide being now the cornerstone of Python packaging (at least it seems to from the look at the https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro) it is getting complicated to package Fedora packages on EPEL-7. Also, the definition of %python_provide is so cumbersome, that it cannot be easily included in the SPEC file itself.

Version-Release number of selected component (if applicable):
python-rpm-macros-3-6.el7.1.noarch

Comment 1 Orion Poplawski 2016-05-14 14:06:36 UTC
%python_provide is in EPEL-7.

If you want to package Fedora packages on EPEL7, they need to use:

%{?python_provide:%python_provide python%{python3_pkgversion}-%{srcname}}

Comment 2 Matěj Cepl 2016-05-15 05:57:06 UTC
Created attachment 1157612 [details]
example SPEC file

Building of this package with this SPECFILE ends with:

$ fedpkg --dist epel7 local
error: line 1: Unknown tag: %python_provide: ERROR: %python34-%{srcname} not recognized.
error: query of specfile /home/matej/build/EXTRAS/python3-mypy/python3-mypy.spec failed, can't parse

Could not execute local: Could not get n-v-r-e from '\n'
$

Most likely it somehow relates to bug 1249039 (python3 package for EPEL is skewed much in many places, e.g., it doesn't have Provides: python3), but still. This just doesn't work.

Comment 3 Orion Poplawski 2016-05-15 14:43:14 UTC
We, first off, if you are going to use %{srcname} you need to define %{srcname}:

%global srcnamne mypy

Second, you've added an additional % in front of python%{python3_pkgversion} in your version.

Comment 4 marcindulak 2016-12-08 14:41:36 UTC
This is a real problem and it appears when trying to perform a koji build for a python34 package for EPEL7 from a Fedora 23 machine: Fedora does not understand what python34 is:

[centos7]$ cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 
[centos7]$ rpm --eval '%python_provide python34-test'
[centos7]$ rpm --eval '%python_provide python3-test'
%python_provide: ERROR: python3-test not recognized.

[fedora23]$ cat /etc/redhat-release 
Fedora23 release 23 (Twenty Three)
[fedora23]$ rpm --eval '%python_provide python34-test'
%python_provide: ERROR: python34-test not recognized.
[fedora23]$ rpm --eval '%python_provide python3-test'

I've followed the Python packaging document for https://bugzilla.redhat.com/show_bug.cgi?id=1398369 and I'm blocked at epel7 `  fedpkg build --nowait` with:

error: line 54: Unknown tag: %python_provide: ERROR: python34-idstools not recognized.
error: query of specfile /vagrant/python-idstools/python-idstools.spec failed, can't parse

Please reopen and investigate. I guess Fedora should know about python34. Why Fedora an RHEL differ in this respect?

Comment 5 Jason Tibbitts 2016-12-08 15:09:32 UTC
Fedora and EPEL differ because they have different python stacks.  You shouldn't be hardcoding the "3" or "34" if you want a package which builds across Fedora and EPEL without changes.  That's what %python3_pkgversion is for.

Comment 6 marcindulak 2016-12-08 21:30:59 UTC
The documentation at https://fedoraproject.org/wiki/Packaging:Python does not mention %python3_pkgversion. I guess the only changes needed there are to replace python3 with python%python3_pkgversion in:

%package -n python3-%{srcname}
%{?python_provide:%python_provide python3-%{srcname}}
%description -n python3-%{srcname}

Comment 7 marcindulak 2016-12-08 21:33:29 UTC
and in

%files -n python3-%{srcname}

Comment 8 Jason Tibbitts 2016-12-08 22:24:37 UTC
It's not mentioned because Fedora has no need for it; your issue is related to EPEL.  If the EPEL packaging guidelines don't have a mention of it then they probably should.

Comment 9 marcindulak 2016-12-08 23:11:31 UTC
I would opt for changing the Fedora instructions, otherwise the situation requires answering the same question over and over again:

April 2016: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/OF5QJJVNFMPVOVRDWWENBJQEMVHQNHX5/

May and December 2016: bug #1336097

July 2016: bug #1355810

October 2016: bug #1381029

Note that in the latter case the packager didn't obtain the answer and we still have no EPEL7 of https://apps.fedoraproject.org/packages/python-more-itertools

Comment 10 Tim Orling 2016-12-09 04:08:58 UTC
From Fedora 23, I perform my EPEL builds using the git SCM syntax for koji, e.g.
"koji build epel7-candidate git://pkgs.fedoraproject.org/rpms/python-idstools.git?#6f08a02d4ac6828c30cae88ee5444e4ec2b6f9cc"

I also use a CentOS7 VM to perform "native" builds and for fedora-review of EPEL packages.

Be creative. The tools are all there.

Comment 11 Sergio Basto 2017-02-14 04:45:54 UTC
wiki documentation is here: 
https://fedoraproject.org/wiki/PackagingDrafts:Python3EPEL

use may use: 
%{?python_provide:%python_provide python%{python3_pkgversion}-%{srcname}}

Comment 12 Michal Ambroz 2019-11-09 01:07:49 UTC
I guess build root was just missing the epel-rpm-macros.


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