On Fri, Dec 6, 2019 at 11:12 AM Thomas Deutschmann <whi...@gentoo.org> wrote: > > On 2019-12-06 16:48, Mike Gilbert wrote: > > It's not quite so simple as you make it sound. There really isn't a > > viable way to defer removal of python2-only packages until we remove > > dev-lang/python:2.7. > > > > An increasing number of python packages are dropping support for > > python2 when upstream releases new versions. When this happens, we > > really need to drop python2 support from all reverse dependencies as > > well. Alternative strategies like slotting or compatibility packages > > are a stopgap at best, and become a problem as soon as bugs are > > reported or security issues pop up. > > > > Ripping out python2 support for all reverse dependencies of a core > > package is rather daunting, and is likely to cause much more of an > > uproar than the recent mask. Aaron is really tackling the low-hanging > > fruit at this point: leaves on the depgraph. > > But what's the problem here? Why do you need to rip out Py2 support? PHP > project is facing a similar situation with PHP 5.6, 7.0 and now 7.1 > becoming EOL. Sure, there are way more Python packages but could you > explain why you can't do the same like we did? I.e. new versions of PHP > PECL extension also dropped support for PHP versions which are EOL. When > we bump these packages we just drop PHP versions which are no longer > able to run these extensions. But we keep at least last version still > supporting PHP version which is/become EOL until we finally get rid of > this PHP version as a whole. For example, a lot of packages are now > masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of > PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users > by starting to remove PECL extension for this version while > dev-lang/php:5.6 was still a thing...
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. Option 1 is bad because the user will be missing out on bug fixes and new features. Option 2 will probably generate some bug reports that we will have to close as CANTFIX. 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.