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