1 |
On Fri, Dec 6, 2019 at 11:12 AM Thomas Deutschmann <whissi@g.o> wrote: |
2 |
> |
3 |
> On 2019-12-06 16:48, Mike Gilbert wrote: |
4 |
> > It's not quite so simple as you make it sound. There really isn't a |
5 |
> > viable way to defer removal of python2-only packages until we remove |
6 |
> > dev-lang/python:2.7. |
7 |
> > |
8 |
> > An increasing number of python packages are dropping support for |
9 |
> > python2 when upstream releases new versions. When this happens, we |
10 |
> > really need to drop python2 support from all reverse dependencies as |
11 |
> > well. Alternative strategies like slotting or compatibility packages |
12 |
> > are a stopgap at best, and become a problem as soon as bugs are |
13 |
> > reported or security issues pop up. |
14 |
> > |
15 |
> > Ripping out python2 support for all reverse dependencies of a core |
16 |
> > package is rather daunting, and is likely to cause much more of an |
17 |
> > uproar than the recent mask. Aaron is really tackling the low-hanging |
18 |
> > fruit at this point: leaves on the depgraph. |
19 |
> |
20 |
> But what's the problem here? Why do you need to rip out Py2 support? PHP |
21 |
> project is facing a similar situation with PHP 5.6, 7.0 and now 7.1 |
22 |
> becoming EOL. Sure, there are way more Python packages but could you |
23 |
> explain why you can't do the same like we did? I.e. new versions of PHP |
24 |
> PECL extension also dropped support for PHP versions which are EOL. When |
25 |
> we bump these packages we just drop PHP versions which are no longer |
26 |
> able to run these extensions. But we keep at least last version still |
27 |
> supporting PHP version which is/become EOL until we finally get rid of |
28 |
> this PHP version as a whole. For example, a lot of packages are now |
29 |
> masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of |
30 |
> PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users |
31 |
> by starting to remove PECL extension for this version while |
32 |
> dev-lang/php:5.6 was still a thing... |
33 |
|
34 |
That's going to cause a very confusing user-experience due to |
35 |
conflicting PYTHON_TARGETS values on the various packages. It's also |
36 |
going to cause users to have old/unsupported/buggy versions of various |
37 |
random python packages depending on what set of reverse dependencies |
38 |
they happen to have installed. |
39 |
|
40 |
For example, lets say the next release of dev-python/example drops |
41 |
support for python2, and also adds some new features and fixes some |
42 |
bugs. |
43 |
|
44 |
If the user has python2_7 enabled for any reverse dependency of |
45 |
dev-python/example, Portage will be forced to do one of two things: |
46 |
|
47 |
1. Keep the old version installed. |
48 |
2. Emit a confusing error message to the user since the use-dependency |
49 |
on dev-python/example[python_targets_python2_7] cannot be resolved |
50 |
with the latest visible version. |
51 |
|
52 |
Option 1 is bad because the user will be missing out on bug fixes and |
53 |
new features. Option 2 will probably generate some bug reports that we |
54 |
will have to close as CANTFIX. |
55 |
|
56 |
It's also a giant pain in the butt for python maintainers since it |
57 |
makes cleaning up old versions very error-prone. This may also be a |
58 |
problem if the security team demands we remove it. |