On 20 June 2017 at 12:44, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote:
> On 20 June 2017 at 02:49, Przemek Klosowski <przemek.klosowski@xxxxxxxx> wrote:
>> It seems to me that there are two kinds of Python packages affected by this
>> issue: some track the evolution of the ecosystem and make sure they work
>> with both Python 2 and 3, while the others assume a specific environment,
>> and expect the user to conform to that. What I dislike about this proposal
>> is that it imposes on the first kind: their package name needs to change,
>> presumably to 'pyton3-xxx' even though the package might work with python2
>> as well. This sounds like penalizing the good behavior.
>
> It's also an annoyingly difficult policy to comply with for anyone
> attempting to maintain RHEL/CentOS/EPEL compatible packages that will
> use Py2 in those contexts and Py3 in Fedora.
It was pointed out to me that my description of this problem wasn't
entirely clear, so here's a more concrete example that hopefully
clarifies the problem I see with the current policy wording.
Specifically, the issue I see is that given the current policy
wording, dependency declarations like the following would *not* be
policy compliant for Python packages in Fedora 27+, even though
they're entirely unambiguous about the Python version they expect to
get:
```
%if 0%{?el7} || 0%{?fedora} < 27
BuildRequires: python2-devel
%else
BuildRequires: python3-devel
%endif
BuildRequires: python-builddep1
BuildRequires: python-builddep2
Requires: python-runtimedep1
Requires: python-runtimedep2
```
Such specifications would instead need to be written as:
```
%if 0%{?el7} || 0%{?fedora} < 27
BuildRequires: python2-devel
BuildRequires: python2-builddep1
BuildRequires: python2-builddep2
Requires: python2-runtimedep1
Requires: python2-runtimedep2
%else
BuildRequires: python3-devel
BuildRequires: python3-builddep1
BuildRequires: python3-builddep2
Requires: python3-runtimedep1
Requires: python3-runtimedep2
%endif
```
Requiring such as an approach has the unfortunate effect of making the
spec file both harder to read (since it's less obvious that the
packager's intent is to just use whichever Python version handles the
default package provides on the target OS), and harder to maintain
(since every dependency has to be listed twice).
By contrast, if an explicit "BuildRequires: python3-devel" on F27+ is
taken as an affirmative statement that the package is ready for the
switch of the unqualifed dependencies to Python 3, then the only
packages that would have to change anything are those that currently
have an unqualified dependency on "BuildRequires: python-devel".
Packagers in the latter situation would then have to do one of two things:
1. If their package actually works on Python 3, change their
pythonX-devel dependency to be Fedora version dependent (while leaving
other dependency declarations unchanged):
```
%if 0%{?fedora} < 27
BuildRequires: python2-devel
%else
BuildRequires: python3-devel
%endif
```
2. If their package still genuinely requires Python 2, update all of
their dependency declarations accordingly:
```
BuildRequires: python2-devel
BuildRequires: python2-builddep1
BuildRequires: python2-builddep2
Requires: python2-runtimedep1
Requires: python2-runtimedep2
```
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
