On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote: > On 12/5/2019 09:24, Rich Freeman wrote: > > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx...@gentoo.org > > > wrote: > > > It's quite another to mask random packages that have USE flags to > > > optionally support whatever python 2.7 library. If you're going > > > to > > > last rites these, talk with the maintainer first, and only then, > > > send > > > emails one at a time. Doing that en masse isn't appropriate. > > > > ++ - I have no idea if that happened. For anything USE-controlled > > it > > would make more sense to file a bug or mask the package-flag combo > > itself. > > > > > On another topic, I'd prefer for python 2.7 not to be removed > > > from > > > gentoo. Tons of code still uses it. > > > > > > > I'm sure a million people would share that preference. I'm not > > sure > > what the upstream/security status is of 2.7. Obviously to keep it > > around it would need to be reasonably secure, and somebody within > > Gentoo would have to want to maintain it. That's basically the > > criteria for keeping anything like this around. If somebody > > stepped > > up and said "I'm maintaining 2.7 and here is why it will remain > > secure..." I doubt they'd get a lot of resistance. > > > > I'm late to the party as usual. Seems upstream plans a final 2.7.18 > security update in April of 2020, then they will consider the 2.7 > branch > EOL. They say most of these updates were done in 2019, and so are > still > technically sticking to their mantra of no more updates after > 01/01/2020. > > PEP 373 covers this: > https://www.python.org/dev/peps/pep-0373/#release-schedule > > """ > Planned future release dates: > > 2.7.18 code freeze January, 2020 > 2.7.18 release candidate early April, 2020 > 2.7.18 mid-April, 2020 > """ > > IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER > the > release of 2.7.18. This provides some time for people to transition > systems > off of 2.7-dependent packages. > > It might be worthwhile to treat the removal of Python-2.7 from the > tree in > the same manner as an EAPI deprecation and removal, given how > ingrained it > is due to its longevity. That will minimize the whiplash-effect of > emerge > complaining about slot conflicts and dependency conflicts. Like I > just ran > into w/ setuptools-45.0.0.0's release. >
Thanks for volunteering to help us manage the ton of packages that have dropped py2 in the mean time. I wasn't aware you were part of the python team, but I must have been mistaken!
