Fedora template is not compatible with EPELs

[cejkato2]

pyp2rpm generates:

%{?python_provide:%python_provide python3-%{pypi_name}}

(pyp2rpm tested with fedora/24-cloud-base vagrant)

Unfortunately, this fails on EPEL7 (tested using copr), Fedora works well. Orion Poplawski suggests in https://bugzilla.redhat.com/show_bug.cgi?id=1336097 the following:

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

I can confirm this works, but there is still an issue with EPEL6.

The module I tried to build is nemea-pytrap at pypi.

[cejkato2]

Same issue here: https://copr.fedorainfracloud.org/coprs/cejkat/NEMEA/build/402225/

[hroncok]

Currently, pyp2rpm offers various templates. The default one (on Fedora) is obviously the Fedora template. Template for EPEL is being discussed in #38 (actually feel free to propose there how the template should look like). Once the template will be ready, Copr can make it so that on EPEL buildroots the appropriate template will be set (right @xsuchy?). Until then, I'm afraid this cannot be fixed, pyp2rpm doesn't really know you are going to build this on EPEL and creating one if-elsed spec for Fedora and two EPELs would be a mess.

[cejkato2]

Thanks for reply. Using special template for epel sounds like a good idea. Can anybody tell me how to set copr for this? I think, copr should choose the template automatically by itself... Maybe I should write an issue somewhere else - where?

[hroncok]

Well, the problem is the template does not exist in pyp2rpm yet. Once it's ready, we'll communicate it to Copr devs.

[hroncok]

Can you check if the proposed fix works for you?

[xsuchy]

I am not sure what the proposed fix is actually doing. But generally speaking. In Copr we generate one SRPM which will be then used for all branches. So it will be nice if the template can work in all chroots. E.g. it can have something like:

%if 0%{?rhel} > 0
   something rhel specific
%else
   something fedora specific
%endif

[brianjmurrell]

@hroncok It sounds like @xsuchy answered your question in this comment and replied that your proposed solution does NOT work for him/Copr.

An additional response from the Copr dev(s) in another ticket in Copr about this issue also wants a single spec out of pyp2rpm that can work on all of mageia+EPEL7+Fedora.

I have tested and using python%{python3_pkgversion} instead of python3 in the spec that is generated on Fedora (without a -t template override) does fix the %{python_provide} problem and creates a .spec that is portable across Fedora and EL7.

What is the problem with using python%{python3_pkgversion} instead of python3 in pyp2rpm?

This project and Copr seem at an impasse. How can we all resolve this this in a way that you can both agree on?

[hroncok]

I think we can have a non-default template for fedora+epel combined (if somebody contributes in and will help maintain it).

[brianjmurrell]

I still don't understand why you are so resistive to making the suggested change in the fedora default template. It doesn't break fedora packages and it enables them to build on epel without needing a separate/special template for epel7.

[hroncok]

The default template is used by many. Judged by the package reviews I've participated in, most of the python packages that go into Fedora are created with pyp2rpm (or copy pasted from others cereted with pyp2rpm). Changing the default here will eventually change not only this tool but also a lot of future Fedora packages.

Fedora is not EPEL and while I respect other packagers who desire to maintain a single spec for Fedora rawhide and a 7 years old distro at a same time, I don't want to encourage this. It renders the specfiles unnecessarily complex and hard to read. More importantly, hard to update for others. When we wish to introduce changes into Fedora, this group of packagers is always the loudest about us breaking their single spec files for EPEL 6-7 and Fedora 17 to rawhide. There are packages to this day that have if conditionals for RHEL 4 stuff and Fedora 12! If you wish to write your specfiles in this dreadful way I cannot stop you, but I will not encourage this willingly by making it pyp2rpm default.

A workflow that I support is maintaining different branches for different distros or even different Fedora versions. The update policy for EPEL and Fedora is different. The update policy for rawhide and stable Fedora is different. The branches will eventually diverge anyway naturally.

This is solely my opinion (and this is not the pyp2rpm project opinion, I'm only a small part of it and other more involved developers (mainly @mcyprian and @irushchyshyn) might have different opinions).

The above is all about he default. Now I ask you in return: why is an opt-in option not enough?

---

A specific example: pyp2rpm defaults to the new pythonXdist() feature available in all Fedoras since 26 to speed up the adoption in Fedora. This is unavailable in EPEL and thus would be impossible to do.

[brianjmurrell]

why is an opt-in option not enough?

I'm not sure what this is asking. What opt-in?

[hroncok]

By creating an epel+fedora combined template we'd allow users of pyp2rpm to explicitly opt-in for that template while preserving the modern fedora only template as default. The opposite would be to add the epel stuff to the fedora template and provide an opt-out option, such as a fedora-only template.

[clime]

By crating an epel+fedora combined template we'd allow users of pyp2rpm to explicitly opt-in for that template while preserving the modern fedora only template as default. The opposite would be to add the epel stuff to the fedora template and provide an opt-out option, such as a fedora-only template.

I am largely in favor of this. The template could be called "compat".

[hroncok]

@clime in favor of the opt-in option?

[clime]

@clime in favor of the opt-in option?

Yup. We we can easily change the way we invoke pyp2rpm in COPR so opt-in is no problem for us.

[brianjmurrell]

crating an epel+fedora combined template

Is this something that the maintainers of this project will do and maintain or is it expected that it will be contributed and externally maintained?

[clime]

I looked into the code and gave up after a while. It's definitely possible to do but I don't have caps now to do it.

[hroncok]

Is this something that the maintainers of this project will do and maintain or is it expected that it will be contributed and externally maintained?

A contribution is always welcome. However some of us might eventually do this.

[clime]

This is quite a hot topic in COPR these days. When someone tries to build a package by using pyp2rpm, he usually does that for epel-7 chroot and it usually...fails. An example here:

https://copr-be.cloud.fedoraproject.org/results/iranzo/sarstats/epel-7-x86_64/00723020-python-sarstats/builder-live.log

error: line 25: Unknown tag: %python_provide: ERROR: python3-sarstats not recognized.

In other words...this would be a very cool feature!

[hroncok]

When someone tries to build a package by using pyp2rpm, he usually does that for epel-7 chroot and it usually...fails.

When building for EPEL, they can use EPEL templates.

[hroncok]

Also, EPEL templates are most probably compatible with Fedora. They might not follow the guidelines exactly, but they will work.

[nkadel]

I've done this for py2pack. It's..... work. Fedora 30 gave on python2 by default, and is publishing packages without python2- versions and publishing .spec files without even the hooks. To make it work reliably, you have to set up distinct "with_python2" and "with_python3". You also have to explicitly rename the installed binaries for py2_install or py3_install suffix with a "-%{py2_version}" or "-%{py3_version} to bundle both sets of scripts, and do symlinks to the scripts for the desired default binaries.

It'd doable, but takes more attention, especially to avoid conflicts with binaries that may already have a "-2" or "-3.6" in the name.