On 23 June 2017 at 04:07, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
> There are two downsides to this kind of declaration:
> - python2-runtimedep[12] will be used until the switch to python3 as
> default is made, which might be very long. Instead, we would prefer
> packages to use python3-runtimedep[12] to gradually push out python2.
> - when the switch finally comes, such packages will suddenly switch
> all at once, and such flag days are generally painful.
>
> So instead, I think it'd preferable to introduce a global macro
> %python_preferred_suffix (or a better name), that would evaluate
> to '3' on all Fedora, and '' on EPEL [*]. The deps would then look as:
>
> BuildRequires: python%{python_preferred_suffix}-builddep1
> BuildRequires: python%{python_preferred_suffix}-builddep2
> Requires: python%{python_preferred_suffix}-runtimedep1
> Requires: python%{python_preferred_suffix}-runtimedep2
>
> This would keep things unambiguous, but brief.
Miro suggested something similar (with %{py} as the macro spelling),
and it occurred to me that something like that could instead be made a
recommendation for people to use at the level of their own spec files
rather than something that Fedora provides by default. For example:
```
%if 0%{?el7} || 0%{?fedora} < 25
BuildRequires: python2-devel
%define py_prefix python
%else
BuildRequires: python3-devel
%define py_prefix python3
%endif
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```
That approach avoids my original concern about duplicating the
dependency lists, and it also means we would avoid replacing the
current "default Python" flag day with a new "preferred Python" flag
day. Instead, spec authors would be asked to declare explicitly in
their own spec file when they switched over to using Fedora's Python 3
stack rather than the Python 2 stack.
Which (as it turns out) is exactly what Iryna's original message
proposed, just with more explicit guidance on how to handle that
request in a relatively easy to maintain way :)
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
