Issues making packages for EPEL7

[yanniszark]

Hi all! Awesome work creating this tool, we (Arrikto) are trying to use it to package our Python dependencies.
We are currently having an issue with the generated SPEC files for EPEL 7.

For example, we are trying to build a package for packagemockldap.
These are the generated dependencies:

BuildRequires:  python2-devel
BuildRequires:  python2-funcparserlib = 0.3.6
BuildRequires:  python2-ldap
BuildRequires:  python2-setuptools
BuildRequires:  python2-setuptools >= 0.6~rc11
BuildRequires:  python2-mock
BuildRequires:  python2-sphinx

However, some of those will not work, because there are only python-X packages, not python2-X packages.
I would expect dependencies in EPEL7 to use the unversioned format because:

• If it's an old dependency, it will work.
• If a newer, versioned package has been released, it should declare that it provides the unversioned package.

I see that this format was removed in #128. However, this leads to SPEC files that cannot find the packages they need.

In addition, the SPEC files generated by pyp2rpm for EPEL 7, with the epel7 template, provide only python2-x and not python-x.

My understanding from reading these sources:

• https://python-rpm-porting.readthedocs.io/en/latest/modules.html#python-provide
• https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_python_provide_macro

is that the correct way to do this is by using the python_provide macro.
I see that this macro is available in my RHEL 7 host, so we should be able to use it in the EPEL template.
I also see that other templates are already using it (e.g., the Fedora one).

In conclusion, our proposal is to:

1. Use unversioned python packages for dependencies in EPEL 7.
2. Provide the unversioned package in SPECs generated with pyp2rpm, with the python_provide directive.

What do you think?