The packages that use python-single-r1 and PYTHON_COMPAT=( python2_7 )will fail with * ERROR: dev-db/mysql-workbench-6.3.4-r2::local failed (depend phase): * No supported implementation in PYTHON_COMPAT. * * Call stack: * ebuild.sh, line 609: Called source '/var/db/repos/local/dev-db/mysql-workbench/mysql-workbench-6.3.4-r2.ebuild' * mysql-workbench-6.3.4-r2.ebuild, line 10: Called inherit 'gnome2' 'eutils' 'flag-o-matic' 'python-single-r1' 'cmake-utils' * ebuild.sh, line 314: Called __qa_source '/var/db/repos/local/eclass/python-single-r1.eclass' * ebuild.sh, line 112: Called source '/var/db/repos/local/eclass/python-single-r1.eclass' * python-single-r1.eclass, line 262: Called _python_single_set_globals * python-single-r1.eclass, line 179: Called _python_set_impls * python-utils-r1.eclass, line 156: Called die * The specific snippet of code: * die "No supported implementation in PYTHON_COMPAT." * * If you need support, post the output of `emerge --info '=dev-db/mysql-workbench-6.3.4-r2::local'`, * the complete build log and the output of `emerge -pqv '=dev-db/mysql-workbench-6.3.4-r2::local'`. * The ebuild environment file is located at '/var/tmp/portage/dev-db/mysql-workbench-6.3.4-r2/temp/environment'. * Working directory: '/var/tmp/portage/dev-db/mysql-workbench-6.3.4-r2/homedir' * S: '/var/tmp/portage/dev-db/mysql-workbench-6.3.4-r2/work/mysql-workbench-6.3.4' !!! getFetchMap(): aux_get() error reading dev-db/mysql-workbench-6.3.4-r2; aborting. which affects multiple packages in gentoo and other overlays Reproducible: Always
As of the end of January [1], all Python eclasses except python-any-r1 no longer support Python 2. Python 2.7 deprecation was announced long in advance (at the beginning of 2020 IIRC), and a reminder was sent out in December [2]. This change is not likely to be reverted. [1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=86d403b7707e15059afa36db4576b4771012c86b [2] https://archives.gentoo.org/gentoo-dev/message/a321277c250ee1a5853ebc2e0dda5a6e
Thanks for the clarification. Are there any drawbacks in keeping it? That might kill quite a few ebuilds... especially the old ones. I added python2_7 in the affected eclasses and everything went back to normal. Currently it's only a question of having python2_7 in the list or not. Or are there fears that Python 2.7 will soon not be able to compile in the nearest future?
(In reply to Emily Rowlands from comment #1) > As of the end of January [1], all Python eclasses except python-any-r1 no > longer support Python 2. Python 2.7 deprecation was announced long in > advance (at the beginning of 2020 IIRC), and a reminder was sent out in > December [2]. This change is not likely to be reverted. > Exactly. We only have build time usage now. We did try make this clear... I’m sorry for the inconvenience OP, but it is what it is. FWIW, MySQL Workbench is back in tree: https://packages.gentoo.org/packages/dev-db/mysql-workbench. I recommend that overlay developers subscribe to gentoo-dev and read the news items. > > [1] > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=86d403b7707e15059afa36db4576b4771012c86b > > [2] > https://archives.gentoo.org/gentoo-dev/message/ > a321277c250ee1a5853ebc2e0dda5a6e
OK. Just for the record in this particular case the tree misses 6.x workbench support and 8.x is unable to connect to mysql server < 5.6.0 which is a big problem but had workarounds - it is possible to install workbench 6.x on the current gentoo. And this problem became a bigger with 2_7 drop and the work-around became more complex. (In reply to Sam James from comment #3) > (In reply to Emily Rowlands from comment #1) > > As of the end of January [1], all Python eclasses except python-any-r1 no > > longer support Python 2. Python 2.7 deprecation was announced long in > > advance (at the beginning of 2020 IIRC), and a reminder was sent out in > > December [2]. This change is not likely to be reverted. > > >
