On 06/29/2017 04:20 AM, Adam Williamson wrote:
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'...
Adding python2-foo is the second half of this proposal.
We don't want to do that by *just* adding "Provides: python2-foo" to all
packages, because if everyone did that, we'd need to ask them to change
again in a few years.
Would it be reasonable to do this in phases: first ask everyone to add
python2- provides, then ask everyone to use them? Yes, and in fact, we
already did that: the python2- prefix has been recommended in the
guidelines for a quite a long time. But many packagers won't do the
change until it starts being necessary.
Rebuilding lots of packages in EL6 is practically impossible, actually.
However, some subset of commonly-used packages do have the python2-
prefixed provides even in EL6. The very example above is misleading:
EL6's packages do provide python2-devel.
--
Petr Viktorin