Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!news.etla.org!aioe.org!bofh.it!news.nic.it!robomod
From: Scott Kitterman <debian@kitterman.com>
Newsgroups: linux.debian.maint.python
Subject: Re: Updated PEP 394 (python and python2 commands)
Date: Fri, 18 May 2018 21:20:02 +0200
Message-ID: <vQT50-6sr-5@gated-at.bofh.it>
References: <vQwi5-11b-1@gated-at.bofh.it> <vQQgO-4Je-13@gated-at.bofh.it> <vQRwd-5pL-9@gated-at.bofh.it>
Old-Return-Path: <debian@kitterman.com>
User-Agent: KMail/4.13.3 (Linux/3.13.0-147-generic; KDE/4.13.3; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Approved: robomod@news.nic.it
Lines: 160
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:10566

On Friday, May 18, 2018 07:29:19 PM Matthias Klose wrote:
> On 18.05.2018 18:14, Scott Kitterman wrote:
> > On Friday, May 18, 2018 11:31:37 AM Matthias Klose wrote:
> >> On 18.05.2018 05:19, Piotr O=C5=BCarowski wrote:
> >>> [Matthias Klose, 2018-05-17]
> >>>=20
> >>>> PEP 394 [1] saw an update in April 2018 [2], the diffs at [3].
> >>>>=20
> >>>> The most important change from my point of view is
> >>>>=20
> >>>> -* It is suggested that even distribution-specific packages foll=
ow the
> >>>> -  ``python2``/``python3`` convention, even in code that is not
> >>>> intended
> >>>> to
> >>>> +* It is strongly encouraged that distribution-specific packages=
 use
> >>>> ``python2`` +  or ``python3`` rather than ``python``, even in co=
de that
> >>>> is not intended to>>
> >>>>=20
> >>>>    operate on other distributions.
> >>>=20
> >>> FTR: the day this PEP asks us to point /usr/bin/python to python3=
 is the
> >>> day I start ignoring it, to say the least.
> >>>=20
> >>>> I don't think there is enough time to replace all python shebang=
s to
> >>>> python2 in time for the buster release, however there is no harm=
 in
> >>>> starting this process now.
> >>>=20
> >>> too late, this process has already started (since dh_python2
> >>> v3.20180313)
> >>> ;-P>
> >>>=20
> >>>> But I'd like to get this done for buster+1, in the case we still=
 need
> >>>> to
> >>>> ship a Python2/2.7, so that buster+1 doesn't ship with a python
> >>>> command,
> >>>> but maybe with a python2 command.
> >>>=20
> >>> we already ship /usr/bin/python2. Removing /usr/bin/python makes =
sense
> >>> as well (administrators can symlink it to whatever they want once=
 it's
> >>> gone from Debian), but...
> >>>=20
> >>>> The first step is to create a set of python2* packages in
> >>>> python-defaults, with contain all the python2* symlinks, and hav=
ing the
> >>>> python* packages depend on those python2 packages.  This change =
itself
> >>>> is a no-op and shouldn't affect anything.
> >>>>=20
> >>>> As a second step change the dh_python2 (in python-defaults), and=

> >>>> dh-python to generate dependencies on python2 instead of python,=
 and
> >>>> replacing the shebang from python to python2.
> >>>>=20
> >>>> This should cover the majority of packages to replace dependenci=
es on
> >>>> python with dependencies on python2.  There are packages which d=
on't
> >>>> check for python2, so these probably need adjustments.  But agai=
n, the
> >>>> goal for buster+1 is to ship as few Python2 dependent packages a=
s
> >>>> possible, if any.
> >>>=20
> >>> this is useless. What will we gain by renaming packages?
> >>=20
> >> who said, that we should rename packages? The only packages being =
dropped
> >> are the python defaults packages.
> >>=20
> >>> I refuse to do that work!
> >>=20
> >> There is no work in renaming the packages. It's about the dependen=
cy
> >> generation and the shebang.
> >>=20
> >>> The only message it sends is that we don't think /usr/bin/python =
or
> >>> python package is Python 2.7 anymore and that's definitely not th=
e
> >>> message I want to send.
> >>=20
> >> No, that's not what the PEP says.
> >=20
> > Upstream is free to follow Arch in their insanity (even if more slo=
wly)
> > and
> > suggest pointing /usr/bin/python at a python3 version is a reasonab=
le
> > thing to do (eventually).  It's not (and they even explain why in t=
he
> > PEP).  Debian doesn't have to follow.  We can have higher standards=
.
>=20
> I don't see how "having higher standards" and being explicit about us=
ing
> "python2" are exclusive.

I think /usr/bin/python2 is fine.  It doesn't hurt anything.  We provid=
e it=20
today and should continue to do so.  No package renaming needed.  As PE=
P 394=20
says, there are substantial risks for non-packaged code if /usr/bin/pyt=
hon is=20
pointed at a python3 version.  As long as Debian provides python2.7,=20=

/usr/bin/python should point at python2.7.  Once it's gone, the distro=20=

shouldn't provide /usr/bin/python at all.

The higher standards part is not following the eventual push to make=20=

/usr/bin/python point to a python3 version.  I do not think that Debian=
 should=20
ever do that.

> And I'm asking you how you come to your statement about "Upstream ins=
anity",
> and to your statement that upstream suggests of pointing python to py=
thon3.
> > I don't see any reason to be able to "apt install python2" instead =
of "apt
> > install python".  I think it's perfectly fine the way it is now whe=
re the
> > same package provides /usr/bin/oython and /usr/bin/python2.  If you=

> > exclude eventually pointint /usr/bin/python at a python3 version (a=
nd we
> > should), then there's no value in doing it.
> >=20
> > I agree with Piotr.  I don't think we need to "create a set of pyth=
on2*
> > packages".
>=20
> no, it gives users the freedom what to do with the python link, with =
the
> distro explicitly going away of using the unversioned python.  This d=
oesn't
> hurt the distro.  And the amount of work to do that should not be exc=
essive
> for the set of packages targeted to buster+1, if there are any.

The existing python-defaults package will go away the same time that py=
thon2.7=20
does away.  There's no advantage to be had by providing a python2 set o=
f=20
binaries.

Users can already do what they want with the python link.

Scott K