| 1 |
On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote: |
| 2 |
> On 12/5/2019 09:24, Rich Freeman wrote: |
| 3 |
> > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx2c4@g.o |
| 4 |
> > > wrote: |
| 5 |
> > > It's quite another to mask random packages that have USE flags to |
| 6 |
> > > optionally support whatever python 2.7 library. If you're going |
| 7 |
> > > to |
| 8 |
> > > last rites these, talk with the maintainer first, and only then, |
| 9 |
> > > send |
| 10 |
> > > emails one at a time. Doing that en masse isn't appropriate. |
| 11 |
> > |
| 12 |
> > ++ - I have no idea if that happened. For anything USE-controlled |
| 13 |
> > it |
| 14 |
> > would make more sense to file a bug or mask the package-flag combo |
| 15 |
> > itself. |
| 16 |
> > |
| 17 |
> > > On another topic, I'd prefer for python 2.7 not to be removed |
| 18 |
> > > from |
| 19 |
> > > gentoo. Tons of code still uses it. |
| 20 |
> > > |
| 21 |
> > |
| 22 |
> > I'm sure a million people would share that preference. I'm not |
| 23 |
> > sure |
| 24 |
> > what the upstream/security status is of 2.7. Obviously to keep it |
| 25 |
> > around it would need to be reasonably secure, and somebody within |
| 26 |
> > Gentoo would have to want to maintain it. That's basically the |
| 27 |
> > criteria for keeping anything like this around. If somebody |
| 28 |
> > stepped |
| 29 |
> > up and said "I'm maintaining 2.7 and here is why it will remain |
| 30 |
> > secure..." I doubt they'd get a lot of resistance. |
| 31 |
> > |
| 32 |
> |
| 33 |
> I'm late to the party as usual. Seems upstream plans a final 2.7.18 |
| 34 |
> security update in April of 2020, then they will consider the 2.7 |
| 35 |
> branch |
| 36 |
> EOL. They say most of these updates were done in 2019, and so are |
| 37 |
> still |
| 38 |
> technically sticking to their mantra of no more updates after |
| 39 |
> 01/01/2020. |
| 40 |
> |
| 41 |
> PEP 373 covers this: |
| 42 |
> https://www.python.org/dev/peps/pep-0373/#release-schedule |
| 43 |
> |
| 44 |
> """ |
| 45 |
> Planned future release dates: |
| 46 |
> |
| 47 |
> 2.7.18 code freeze January, 2020 |
| 48 |
> 2.7.18 release candidate early April, 2020 |
| 49 |
> 2.7.18 mid-April, 2020 |
| 50 |
> """ |
| 51 |
> |
| 52 |
> IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER |
| 53 |
> the |
| 54 |
> release of 2.7.18. This provides some time for people to transition |
| 55 |
> systems |
| 56 |
> off of 2.7-dependent packages. |
| 57 |
> |
| 58 |
> It might be worthwhile to treat the removal of Python-2.7 from the |
| 59 |
> tree in |
| 60 |
> the same manner as an EAPI deprecation and removal, given how |
| 61 |
> ingrained it |
| 62 |
> is due to its longevity. That will minimize the whiplash-effect of |
| 63 |
> emerge |
| 64 |
> complaining about slot conflicts and dependency conflicts. Like I |
| 65 |
> just ran |
| 66 |
> into w/ setuptools-45.0.0.0's release. |
| 67 |
> |
| 68 |
|
| 69 |
Thanks for volunteering to help us manage the ton of packages that have |
| 70 |
dropped py2 in the mean time. I wasn't aware you were part of the |
| 71 |
python team, but I must have been mistaken! |
Archives