On Thu, 2017-06-29 at 12:11 +1000, Nick Coghlan wrote:
> 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
> ```
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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
