On Thu, 2017-06-29 at 12:11 +1000, Nick Coghlan wrote:
On 29 June 2017 at 11:39, Adam Williamson
<adamwill(a)fedoraproject.org> 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
```
Erf, well, that seems kinda icky but manageable. Is it really better
than just coming up with some kind of script to at least add the
appropriate "Provides: python2-foo" to all packages (or at least a
large subset of the most commonly-used packages) in EL6/EL7/F24,
though? I mean, that doesn't seem beyond the bounds of possibility, to
just find everything that provides 'python-foo' and make it also
provide 'python2-foo'...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net