On Tue, Jun 20, 2017 at 10:27 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 20 June 2017 at 12:44, Nick Coghlan <ncogh...@gmail.com> wrote:
>> On 20 June 2017 at 02:49, Przemek Klosowski <przemek.klosow...@nist.gov>
>> 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
> ```
If we constrain ourselves to RHEL, then we're screwed until at least
2024. I personally do not see this as a strong enough reason to not
fix our Python packaging globally. If anything, this should be an
incentive for Red Hat engineers to actually fix their Python packages
to match Fedora or at least have the necessary provides the shim both
ways.
One thing I've observed as our biggest failing is that we do a very
bad job of actually rationalizing our own packages to match our
guidelines, for spurious reasons like this, where mistakes that make
it to RHEL dog us in Fedora forever. That's not only dumb, it's
dangerous, as it makes it very hard for us to make our distribution
better and more consistent.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
