On Fri, 2020-06-26 at 22:02 +0100, Sergei Trofimovich wrote: > On Fri, 26 Jun 2020 13:41:13 -0400 > Aaron Bauman <b...@gentoo.org> wrote: > > > On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich <sly...@gentoo.org> > > wrote: > > > On Fri, 26 Jun 2020 11:38:58 +0200 > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > > > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > > > > On Fri, 26 Jun 2020 07:29:45 +0000 > > > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > > > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > <sly...@gentoo.org> napisał(a): > > > > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > > > > Sergei Trofimovich <sly...@gentoo.org> wrote: > > > > > > > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > > > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich > > > wrote: > > > > > > > > > > Give maintainers the chance to act and flag packages that > > > pull in > > > > > > > python:2.7. > > > > > > > > > > Signed-off-by: Sergei Trofimovich <sly...@gentoo.org> > > > > > > > > > > --- > > > > > > > > > > profiles/package.deprecated | 4 ++++ > > > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > > > > b/profiles/package.deprecated > > > > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > > > > --- a/profiles/package.deprecated > > > > > > > > > > +++ b/profiles/package.deprecated > > > > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > > > > > > > +# Sergei Trofimovich <sly...@gentoo.org> (2020-06-20) > > > > > > > > > > +# Deprecated. Consider poring to python 3 and drop > > > support for > > > > > > > python2. > > > > > > > > > > +dev-lang/python:2.7 > > > > > > > > > > + > > > > > > > > > > # Sergei Trofimovich <sly...@gentoo.org> (2020-02-22) > > > > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > > > provider. > > > > > > > > > > # Use that instead. Or even better use none of them. > > > It's a > > > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > > > > Python 2.7, as well as these that support 2.7 in addition > > > to 3 > > > > > > > because > > > > > > > > > they have 2.7 deps. > > > > > > > > > > > > > > > > If we expect actions by developers on both cases I don't see > > > a > > > > > > > problem with that. > > > > > > > > > > > > > > Pushed as: > > > > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > > > > > > > with full text being: > > > > > > > > > > > > > > +# Sergei Trofimovich <sly...@gentoo.org> (2020-06-26) > > > > > > > +# Deprecated. > > > > > > > +# - optional python:2.7 dependency should be dropped if no > > > reverse > > > > > > > +# dependencies are using it. > > > > > > > +# - mandatory python:2.7 depepndency will require package > > > porting > > > > > > > +# or package removal if no reverse dependencies are using > > > it. > > > > > > > +dev-lang/python:2.7 > > > > > > > > > > > > You've just introduced 829 CI warnings > > > > > > > > > > That's the intention. > > > > > > > > > > > effectively disabling the ability to distinguish *new* problems > > > in these packages. > > > > > Correct. Citing above: > > > > > > > > > > "If we expect actions by developers on both cases I don't see a > > > problem with that." > > > > > I assume we still do. > > > > > > > > Not exactly. You've pinpointed the wrong target. > > > > > > > > First of all, we want people to support Python 3. Removing support > > > for > > > > Python 2 is a secondary goal. > > > > > > What is the desired end state here? All packages that depend on > > > python should support python3? > > > > > > > Flagging packages that support Python 2 in addition to Python 3 > > > > and cause no trouble in py2 cleanup is doubtful. > > > > > > What is "py2 cleanup"? I still struggle to understand what packages > > > require change and which do not. Is there one pager doc that explains > > > a few things for me: > > > - How packages are picked for masking? Maybe we can deprecate them > > > instead? Or we (I) can write a bit of code that flags packages > > > requiring > > > maintainers' attention. > > > - What is the expected end state for the "py2 cleanup"? > > > > > > The doc would also be a good link to add to recently added "# Py2 only" > > > masks as well. > > > > > > > Flagging packages that support 2+3 because of their revdeps is not > > > > helpful at all. It's just noise to the maintainer who can't remove > > > py2 > > > > because of revdeps. > > > > > > I agree it can be spammy if we expect to have many packages with > > > python2 support for an extended period of time (3+ months). If it's > > > seen by others as too noisy I can revert the commit now. > > > > > > > Flagging dev-python/pypy* which needs py2 but is entirely outside > > > > the eclass system is not helpful at all. > > > > > > To pick a concrete example: from what I read above I don't see why > > > app-misc/golly was masked for removal. > > > > It was masked because it only supports Py2. The maintainer (you) decided to > > drop Python script support. Problem solved. Easy day. All done. > > A few points: > > 1. "only supports Py2" does not seem to warrant to mask leaf packages > and contradicts to Michał's explanation of cleanup effort: > See > https://archives.gentoo.org/gentoo-dev/message/04d419ebef01e80a43fc3b301e11afb6 > Please reconcile the goals within the python@ team. Ask team lead > if not sure and provide clear guidance for others. "only supports Py2" > is not good enough explanation. > > Leaf packages should be able to stay up to 2021-01-01, no? I'd suggest > adding them to packages.deprecated instead.
Important leaf packages, yes. However, we don't really want to 'surprise' everyone by suddenly masking everything. Splitting it into smaller batches is better, as it gives people effectively more time to choose which packages to save. There's no clear criteria how to determine which packages go first. Some of the packages chosen here wouldn't be my first choice. However, if they were last rited already, I would focus on restoring only these that actually proved some demand. > 2. I decided to drop python support in a hurry to unbreak world upgrade > for users and myself. If I had some time I would prefer to do that in > higher confidence and have a chance to look at python3 support in the > package. > But now I chucked python2 scripting entirely probably breaking a few > users. I don't see it as a good thing. > > After Michał's explanation I am considering to restore python2 support > while I investigate python3 support feasibility. I might have missed a point there. While indeed it is possible to keep py2+py3 in various packages, I have myself been proactively removing py2 where py3 is already available. This is mostly a matter of convenience with the limited tooling we have. Long story short, in all the dependency/conflict mess, the simplest way forward is to iteratively try removing py2 everywhere. This way we slowly release deps. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
