On 29 June 2017 at 11:39, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
> On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:
>> 2) Using `python-` instead of `python2-` in the dependencies for the
>> Python 2 binary RPM [2].
>
> I'm not sure this list is terribly useful, because of the above. There
> are thousands of packages that do this, because the 'python2-' provide
> is not available on some older Fedora release, or on EPEL (and the
> package is maintained for EPEL as well as Fedora). Sprinkling "if (some
> release number condition) then Requires: python2-foo else Requires:
> python-foo" all over your spec is a giant PITA and I for one am not
> very interested in doing it.
>
> IMHO, if there is going to be some kind of requirement that all Python
> requires be explicitly versioned, there needs to be a co-ordinated
> effort to make sure the versioned Provides are available across at
> least EL6, EL7, and all supported Fedora releases *first*.
This was the key concern I raised in response to the initial email,
and our conclusion at the time was:
1. This case does need to be addressed
2. Adding an opaque dependency on buildroot configuration settings
wouldn't be a particularly nice way to handle it, since it forces
every package to switch concurrently, rather than each maintainer
getting to decide when to move from the Python 2 stack to the Python 3
stack for themselves (and that unilateral shift is already going to
happen for unqualified dependency declarations when the virtual
%python_provides macro moves from the Python 2 stack to the Python 3
stack)
3. Ideally, the recommended approach would work for arbitrary RHEL &
CentOS based buildroots, not just those with the EPEL RPM macros
available
The most straightforward solution we came up with was for affected
packages to define their own "%py_prefix" macro that selects the stack
they want to use based on the Python version:
```
# The block below would become the conventional
# "Python stack compatibility" dance for
# EL6, EL7, and Fedora
# Each package can decide for itself which version of
# Fedora had a sufficiently complete Py3 stack for
# them to be able to switch over
# Current EL releases & older Fedora use "python-*"
%if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
%define py_prefix python
%if 0%{?el6} || 0%{?el7}
BuildRequires: python-devel
%else
BuildRequires: python2-devel
%endif
%else
# Newer Fedora releases use "pythonX-*"
# A Py2-only project would use "python2" here
%define py_prefix python3
BuildRequires: python3-devel
%endif
# Dependency declarations use stack selected above
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```
For dual stack libraries, the appropriate prefixes to define would be
separate ones for each stack (%py2_prefix and %py3_prefix), and either
leave the latter undefined for systems with no native Py3 stack, or
else set it to rely on EPEL, IUS, or a suitable software collection.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
