1 |
On 2019-12-06 17:44, Mike Gilbert wrote: |
2 |
> That's going to cause a very confusing user-experience due to |
3 |
> conflicting PYTHON_TARGETS values on the various packages. It's also |
4 |
> going to cause users to have old/unsupported/buggy versions of various |
5 |
> random python packages depending on what set of reverse dependencies |
6 |
> they happen to have installed. |
7 |
> |
8 |
> For example, lets say the next release of dev-python/example drops |
9 |
> support for python2, and also adds some new features and fixes some |
10 |
> bugs. |
11 |
> |
12 |
> If the user has python2_7 enabled for any reverse dependency of |
13 |
> dev-python/example, Portage will be forced to do one of two things: |
14 |
> |
15 |
> 1. Keep the old version installed. |
16 |
> 2. Emit a confusing error message to the user since the use-dependency |
17 |
> on dev-python/example[python_targets_python2_7] cannot be resolved |
18 |
> with the latest visible version. |
19 |
|
20 |
I don't fully understand #2 to be honest but yes, you will be cut off |
21 |
from latest version at some point. Same in PHP. |
22 |
|
23 |
But from my POV you are trying to find a solution for a non-existent |
24 |
problem: Keep in mind that *user* is in control of PYTHON_TARGETS |
25 |
(PHP_TARGETS). |
26 |
|
27 |
If we expect that our users should simply remove that mask locally |
28 |
("OMG! It's just a package.mask!") we can assume that same user |
29 |
understand consequences when sticking to targets not supported by newer |
30 |
versions anymore. |
31 |
|
32 |
Also, problem will automatically go away when time passes assuming more |
33 |
and more packages will no longer have python_targets_python2_7. I.e. |
34 |
user will automatically migrate to Py3 over time. |
35 |
|
36 |
I still have no words for this decision breaking working Py 2 *only* |
37 |
packages 150+ days in advance which don't cause any problems (and aside |
38 |
USE=test case will never cause problems -- if pytest for example will |
39 |
become a problem, dropping tests but keeping the package itself is also |
40 |
an option, just saying). |
41 |
|
42 |
Especially now that I adopted that package, no problem was really solved |
43 |
and at some point we will have to discuss test dependencies for example. |
44 |
|
45 |
So yeah, even after 24h I still think this was a bad decision which |
46 |
wasn't thought through to the end. An easy solution for a not yet |
47 |
existing problem. Purely activism in a bad way. :/ |
48 |
|
49 |
|
50 |
> It's also a giant pain in the butt for python maintainers since it |
51 |
> makes cleaning up old versions very error-prone. This may also be a |
52 |
> problem if the security team demands we remove it. |
53 |
|
54 |
We would never do that and you know that. The only thing we would ask |
55 |
you to do is masking to inform user in case user isn't aware that |
56 |
package is vulnerable. But more important: In that case you would have |
57 |
your reason to mask affected dependencies (like PHP project did with PHP |
58 |
5.6 and consumers). |
59 |
|
60 |
Maybe someday one of those responsible will admit that this step was not |
61 |
a thoughtful and good decision and promise not to do it that way again |
62 |
and I'll get over it. Who knows. :) |
63 |
|
64 |
|
65 |
-- |
66 |
Regards, |
67 |
Thomas Deutschmann / Gentoo Linux Developer |
68 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |