public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] unsanctioned python 2.7 crusade
Date: Sun, 12 Jan 2020 17:07:24 -0500	[thread overview]
Message-ID: <15005ba1-1a1b-5d71-dbe3-7834b79ee733@gentoo.org> (raw)
In-Reply-To: <CAGfcS_=zjnTO-OH4kbWbBTQRPTnbPq_8G7J9UQdifr+V_drkhw@mail.gmail.com>

On 12/5/2019 09:24, Rich Freeman wrote:
> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx2c4@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.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
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


  parent reply	other threads:[~2020-01-12 22:07 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 13:42 [gentoo-dev] unsanctioned python 2.7 crusade Jason A. Donenfeld
2019-12-05 13:55 ` Rich Freeman
2019-12-05 13:59   ` Jason A. Donenfeld
2019-12-05 14:24     ` Rich Freeman
2019-12-05 14:34       ` William Breathitt Gray
2019-12-05 14:40         ` Aaron Bauman
2019-12-06  6:53           ` Kent Fredric
2020-01-12 22:07       ` Joshua Kinard [this message]
2020-01-12 22:17         ` David Seifert
2020-01-12 22:29           ` Joshua Kinard
2020-01-12 22:32         ` Andreas Sturmlechner
2020-01-12 22:43           ` Joshua Kinard
2020-01-12 22:46             ` David Seifert
2020-01-12 22:55               ` Joshua Kinard
2020-01-12 23:17                 ` David Seifert
2020-01-13  0:21                   ` William Hubbs
2020-01-13  0:44                     ` Joshua Kinard
2020-01-13  7:22                       ` Andreas Sturmlechner
2020-01-13  6:52         ` Michał Górny
2020-01-14  6:45           ` Joshua Kinard
2019-12-05 20:31     ` David Seifert
2019-12-05 20:56       ` Thomas Deutschmann
2019-12-05 22:23         ` David Seifert
2019-12-05 22:41           ` Rich Freeman
2019-12-06  8:11           ` Mart Raudsepp
2019-12-06 10:48             ` David Seifert
2019-12-06 13:06             ` Thomas Deutschmann
2019-12-06 13:52               ` Rich Freeman
2019-12-06 15:48                 ` Mike Gilbert
2019-12-06 16:12                   ` Thomas Deutschmann
2019-12-06 16:44                     ` Mike Gilbert
2019-12-06 19:47                       ` Thomas Deutschmann
2019-12-06 20:10                         ` Andreas Sturmlechner
2019-12-06 20:28                           ` Thomas Deutschmann
2019-12-08 10:28                             ` Alexis Ballier
2019-12-06 20:30                           ` Michael 'veremitz' Everitt
2019-12-07  8:04                           ` Kent Fredric
2019-12-06 16:35               ` Mart Raudsepp
2019-12-06 16:43                 ` Thomas Deutschmann
2019-12-05 14:36 ` Aaron Bauman
2019-12-05 16:03 ` Andreas K. Huettel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15005ba1-1a1b-5d71-dbe3-7834b79ee733@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox