Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder4.news.weretis.net!news.mixmin.net!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 18:20:02 +0200
Message-ID: <vQQgO-4Je-13@gated-at.bofh.it>
References: <vQwi5-11b-1@gated-at.bofh.it> <vQJS2-Kf-25@gated-at.bofh.it> <vQPE5-4gw-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: 107
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:10559

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 follow=
 the
> >> -  ``python2``/``python3`` convention, even in code that is not in=
tended
> >> to
> >> +* It is strongly encouraged that distribution-specific packages u=
se
> >> ``python2`` +  or ``python3`` rather than ``python``, even in code=
 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 i=
s the
> > day I start ignoring it, to say the least.
> >=20
> >> I don't think there is enough time to replace all python shebangs =
to
> >> python2 in time for the buster release, however there is no harm i=
n
> >> starting this process now.
> >=20
> > too late, this process has already started (since dh_python2 v3.201=
80313)
> > ;-P>=20
> >> But I'd like to get this done for buster+1, in the case we still n=
eed to
> >> ship a Python2/2.7, so that buster+1 doesn't ship with a python co=
mmand,
> >> but maybe with a python2 command.
> >=20
> > we already ship /usr/bin/python2. Removing /usr/bin/python makes se=
nse
> > as well (administrators can symlink it to whatever they want once i=
t'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 havin=
g the
> >> python* packages depend on those python2 packages.  This change it=
self
> >> 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, a=
nd
> >> replacing the shebang from python to python2.
> >>=20
> >> This should cover the majority of packages to replace dependencies=
 on
> >> python with dependencies on python2.  There are packages which don=
't
> >> check for python2, so these probably need adjustments.  But again,=
 the
> >> goal for buster+1 is to ship as few Python2 dependent packages as
> >> 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 dro=
pped
> 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 dependency
> 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 the
> > message I want to send.
>=20
> No, that's not what the PEP says.

Upstream is free to follow Arch in their insanity (even if more slowly)=
 and=20
suggest pointing /usr/bin/python at a python3 version is a reasonable t=
hing to=20
do (eventually).  It's not (and they even explain why in the PEP).  Deb=
ian=20
doesn't have to follow.  We can have higher standards.

I don't see any reason to be able to "apt install python2" instead of "=
apt=20
install python".  I think it's perfectly fine the way it is now where t=
he same=20
package provides /usr/bin/oython and /usr/bin/python2.  If you exclude=20=

eventually pointint /usr/bin/python at a python3 version (and we should=
), then=20
there's no value in doing it.

I agree with Piotr.  I don't think we need to "create a set of python2*=
=20
packages".

Scott K