From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-89558-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 8AF5E138334
for <garchives@archives.gentoo.org>; Fri, 6 Dec 2019 16:45:00 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 1B24DE089A;
Fri, 6 Dec 2019 16:44:58 +0000 (UTC)
Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 46D8CE0875
for <gentoo-dev@lists.gentoo.org>; Fri, 6 Dec 2019 16:44:57 +0000 (UTC)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: floppym)
by smtp.gentoo.org (Postfix) with ESMTPSA id 2213534D854
for <gentoo-dev@lists.gentoo.org>; Fri, 6 Dec 2019 16:44:56 +0000 (UTC)
Received: by mail-io1-f41.google.com with SMTP id i11so7925458ioi.12
for <gentoo-dev@lists.gentoo.org>; Fri, 06 Dec 2019 08:44:56 -0800 (PST)
X-Gm-Message-State: APjAAAWNuAFNcRZpT6QDVkxTwkYBHugzQ2aOAcbeXI0yA1x7U7DuOmXF
x2q3RyqF6FPwc6M0lIBt4uXI1U9GOq/5Iv4hZK4=
X-Google-Smtp-Source: APXvYqwLoXxuOnYIFSja8sGbMcWuFymU+234a2QMHqR6jl4UGsFVRe7e3My5PL1gDIz+QnEC8ia8fGdpfzzcftQWsVo=
X-Received: by 2002:a6b:6202:: with SMTP id f2mr10838324iog.272.1575650694199;
Fri, 06 Dec 2019 08:44:54 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <CAHmME9qRcahsTHju527n0Figd7o8d7-tS_ZmdFBgUBALms5xAg@mail.gmail.com>
<CAGfcS_=mLOmKScFumzfQ5T2jNOFRnRB9=L3H0e040AiuXExt8g@mail.gmail.com>
<CAHmME9rdvViA05_cgfPrQ=Sd9gumaNaGJE-k8kWarCe3vX6f3g@mail.gmail.com>
<51dddccd576fb1203457a09f305bac5a48eaae6c.camel@gentoo.org>
<a29f9820-1f82-6c64-3202-f8358b1220e2@gentoo.org> <20f5820a902edd121bd49195c4adc2f5cea84fa8.camel@gentoo.org>
<f61edf7e92b9cdcd9b8d7bf4c38465efddc31911.camel@gentoo.org>
<33a433c0-b547-7be6-f61a-1cf29b92328a@gentoo.org> <CAGfcS_mOfMkCLc_NqHuOK+7RKRz=0kWgGK0T_33GAUxO7zJmCA@mail.gmail.com>
<CAJ0EP42jk_K4SjG7Tf_P5_CkSaXDJ05aHOpjHFjzhr+kUMg=Xw@mail.gmail.com> <c1e342e6-a2db-95ac-dc61-63ef6fcc7443@gentoo.org>
In-Reply-To: <c1e342e6-a2db-95ac-dc61-63ef6fcc7443@gentoo.org>
From: Mike Gilbert <floppym@gentoo.org>
Date: Fri, 6 Dec 2019 11:44:43 -0500
X-Gmail-Original-Message-ID: <CAJ0EP43BspHFCh-izarz_+pNeLM1qPTA90irdbEDHQwtkW-Ofg@mail.gmail.com>
Message-ID: <CAJ0EP43BspHFCh-izarz_+pNeLM1qPTA90irdbEDHQwtkW-Ofg@mail.gmail.com>
Subject: Re: [gentoo-dev] unsanctioned python 2.7 crusade
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset="UTF-8"
X-Archives-Salt: 14271620-18ae-4d11-b7f3-c63561f8c51e
X-Archives-Hash: c642c33d3ee443dd21cc399520dad8da
On Fri, Dec 6, 2019 at 11:12 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2019-12-06 16:48, Mike Gilbert wrote:
> > It's not quite so simple as you make it sound. There really isn't a
> > viable way to defer removal of python2-only packages until we remove
> > dev-lang/python:2.7.
> >
> > An increasing number of python packages are dropping support for
> > python2 when upstream releases new versions. When this happens, we
> > really need to drop python2 support from all reverse dependencies as
> > well. Alternative strategies like slotting or compatibility packages
> > are a stopgap at best, and become a problem as soon as bugs are
> > reported or security issues pop up.
> >
> > Ripping out python2 support for all reverse dependencies of a core
> > package is rather daunting, and is likely to cause much more of an
> > uproar than the recent mask. Aaron is really tackling the low-hanging
> > fruit at this point: leaves on the depgraph.
>
> But what's the problem here? Why do you need to rip out Py2 support? PHP
> project is facing a similar situation with PHP 5.6, 7.0 and now 7.1
> becoming EOL. Sure, there are way more Python packages but could you
> explain why you can't do the same like we did? I.e. new versions of PHP
> PECL extension also dropped support for PHP versions which are EOL. When
> we bump these packages we just drop PHP versions which are no longer
> able to run these extensions. But we keep at least last version still
> supporting PHP version which is/become EOL until we finally get rid of
> this PHP version as a whole. For example, a lot of packages are now
> masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of
> PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users
> by starting to remove PECL extension for this version while
> dev-lang/php:5.6 was still a thing...
That's going to cause a very confusing user-experience due to
conflicting PYTHON_TARGETS values on the various packages. It's also
going to cause users to have old/unsupported/buggy versions of various
random python packages depending on what set of reverse dependencies
they happen to have installed.
For example, lets say the next release of dev-python/example drops
support for python2, and also adds some new features and fixes some
bugs.
If the user has python2_7 enabled for any reverse dependency of
dev-python/example, Portage will be forced to do one of two things:
1. Keep the old version installed.
2. Emit a confusing error message to the user since the use-dependency
on dev-python/example[python_targets_python2_7] cannot be resolved
with the latest visible version.
Option 1 is bad because the user will be missing out on bug fixes and
new features. Option 2 will probably generate some bug reports that we
will have to close as CANTFIX.
It's also a giant pain in the butt for python maintainers since it
makes cleaning up old versions very error-prone. This may also be a
problem if the security team demands we remove it.