On 23 June 2017 at 04:07, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> 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(a)gmail.com | Brisbane, Australia