Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Joshua Kinard]

On 1/12/2020 17:17, David Seifert wrote:
> 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 <zx2c4@g.o
>>>> 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!

I'm not, heh.  But I have noticed the increasing difficulty of getting
emerge to do clean updates recently because of these removals, especially
when you go several weeks between --sync updates on a machine.  The status
of py2 removal does not seem to have been communicated really well, nor any
kind of plan agreed upon, like we've done w/ the EAPI removal.

If I had more time outside of work, I'd love to help.  But it's a struggle
enough right now to keep my systems ~arch updated, especially since my MIPS
boxes aren't exactly speed demons.  Right now, I'm just suggesting that
maybe we should apply the brakes a little bit and try to coordinate how to
remove py2 completely, rather than the way it's being done now.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic