I suggest to disable "python_targets_python2_7" USE flag by default for sys-apps/portage and some reverse dependencies. (I.e. changing of default USE flags without masking of this flag.) Majority of users use Portage / Repoman / Layman etc. only as executables and do not need to import their code with Python 2. dev-python/pyxattr will be avoided for users of sys-apps/portage[xattr] (especially users of Gentoo Hardened where "xattr" USE flag is forced for sys-apps/portage). This change should result in Python 2 being again absent in stages, so stages will be noticeably smaller.
Created attachment 465656 [details, diff] Patch Patch for gentoo.git, not portage.git.
@python, do you see any issues with disabling python_targets_python2_7 for the packages in the attached patch? This seems pretty reasonable to me. If any users need to reverse these changes, autounmask should easily solve it for them. From dc46a24e657247ae18d78e4e7dbf9428c9e346d2 Mon Sep 17 00:00:00 2001 From: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> Date: Wed, 1 Mar 2017 20:35:02 +0100 Subject: [PATCH] profiles/base/package.use: Disable python_targets_python2_7 for sys-apps/portage and some reverse dependencies. --- profiles/base/package.use | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/profiles/base/package.use b/profiles/base/package.use index bc118bf6c4..ce42ec4f80 100644 --- a/profiles/base/package.use +++ b/profiles/base/package.use @@ -1,6 +1,22 @@ # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 +# Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> (01 Mar 2017) +# Disable Python 2 for Portage and some reverse dependencies by default. +app-admin/webapp-config -python_targets_python2_7 +=app-portage/cpuid2cpuflags-1* -python_targets_python2_7 +app-portage/diffmask -python_targets_python2_7 +app-portage/flaggie -python_targets_python2_7 +app-portage/g-sorcery -python_targets_python2_7 +app-portage/gentoolkit -python_targets_python2_7 +app-portage/gentoolkit-dev -python_targets_python2_7 +app-portage/gentoopm -python_targets_python2_7 +app-portage/layman -python_targets_python2_7 +app-portage/portpeek -python_targets_python2_7 +app-portage/repoman -python_targets_python2_7 +dev-java/java-config -python_targets_python2_7 +sys-apps/portage -python_targets_python2_7 + # Only python3 supported dev-libs/libixion python_single_target_python3_4 dev-libs/liborcus python_single_target_python3_4 -- 2.12.0
It seems fine to me, assuming it doesn't randomly break stages in some unforeseen way.
Let's CC all involved parties and releng.
Fine by me.
Ack (portpeek)
Unfortunately, I have not had time to devote to porthole in the last few years. So, it is behind any python conversion to python3 (it has had none). It relies on portage API's for much of it's data. The emerge process is done via calling emerge, so is not a problem. I should put it's update/python3 porting on the GSOC ideas page. It would make a good project for a student. Aside from py3, there are a number of changes to the tree that it needs to be updated for like no changelogs by default/git tree's having git log capability... I'll look into what it will take to port the gtk interface to py3. The portage backend code won't be an issue, and should be straightforward. Gentoolkit, layman are all python3 capable, so is esearch. Catalyst-3, is also fully python3 compatible, but is not quite in full production use. I'll be able to merge a few more updates after SCALE, make another release. It does use a few portage API's. app-portage/pfl is 2.7 only and has portage in RDEPEND, It uses portage api's. cc'in them. A quick look at it's main file, it should not be difficult to port (maybe a day). app-portage/euscan is also py2.7 only and uses some API's as I recall. cc'in Patrick. Well we already know how he feels about python 3, not to mention the fragile state euscan is in at the moment. Patrick, we should add euscan to the GSOC ideas page. Hopefully we can get a good student to work some much needed magic on it. So, my initial perusal shows 3 API consumers stuck at python-2.7 at this point. So, we are not able to drop python-2.7 ebuild support at this time. Perhaps we can revisit this in the fall.
For consistency, it seems like it would be preferable to disable python_targets_python2_7 globally by default. I wonder if that's feasible? These are the current reverse dependencies from stage3-amd64-20170713: > dev-lang/python-2.7.12 pulled in by: > dev-python/appdirs-1.4.3 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/certifi-2017.4.17 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/packaging-16.8 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyparsing-2.1.10 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/pyxattr-0.5.5 requires >=dev-lang/python-2.7.5-r2:2.7 > dev-python/setuptools-34.0.2-r1 requires >=dev-lang/python-2.7.5-r2:2.7[xml(+)] > dev-python/six-1.10.0 requires >=dev-lang/python-2.7.5-r2:2.7 > sys-apps/portage-2.3.6 requires >=dev-lang/python-2.7.5-r2:2.7[bzip2(+),threads(+)], >=dev-lang/python-2.7.5-r2:2.7[ssl(+)]
If we just disable python_targets_python2_7 for sys-apps/portage, that's enough to eliminate dev-python/pyxattr and its dependencies including python2.7. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > Created attachment 465656 [details, diff] [details, diff] > Patch > > Patch for gentoo.git, not portage.git. The list of packages has to be longer if we want to cover the dependencies of all the packages that you have listed there. For example, this is what I'm seeing if I try to emerge the packages that you have listed: > [ebuild R ] dev-python/six-1.10.0::gentoo USE="-doc {-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/appdirs-1.4.3::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/pyparsing-2.1.10::gentoo USE="-doc -examples" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/PySocks-1.5.6::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-python3_5) (-python3_6)" > [ebuild N ] dev-python/backports-1.0::gentoo PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/packaging-16.8::gentoo USE="{-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/setuptools-34.0.2-r1::gentoo USE="{-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/certifi-2017.4.17::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/pyasn1-0.2.3::gentoo USE="-doc" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/idna-2.5::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild N ] dev-python/enum34-1.1.6::gentoo USE="-doc" PYTHON_TARGETS="python2_7 (-pypy) (-pypy3)" > [ebuild R ] dev-python/ply-3.9::gentoo USE="-examples" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/py-1.4.30::gentoo USE="-doc {-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/chardet-2.3.0::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild N ] dev-python/backports-ssl-match-hostname-3.5.0.1-r1::gentoo PYTHON_TARGETS="python2_7 python3_4 (-pypy)" > [ebuild N ] dev-python/ipaddress-1.0.18::gentoo PYTHON_TARGETS="python2_7 (-pypy)" > [ebuild R ] dev-python/pycparser-2.14::gentoo USE="{-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] virtual/python-ipaddress-1.0-r1::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/cffi-1.9.1:0/1.9.1::gentoo USE="-doc {-test}" PYTHON_TARGETS="python2_7* python3_4 (-python3_5) (-python3_6)" > [ebuild R ] dev-python/cryptography-1.7.1::gentoo USE="(-libressl) {-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/pyopenssl-16.2.0::gentoo USE="-doc -examples {-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/ndg-httpsclient-0.4.0::gentoo PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/urllib3-1.16::gentoo USE="-doc {-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-python3_5) (-python3_6)" > [ebuild R ] dev-python/requests-2.12.5::gentoo USE="{-test}" PYTHON_TARGETS="python2_7* python3_4 (-pypy) (-pypy3) (-python3_5) (-python3_6)" This makes me think it's better to disable python_targets_python2_7 globally, and then enable it selectively.
I think this is possible to do now.
python_targets_python2_7 is no longer in PYTHON_COMPAT since https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a2c520e735f285a11e2486cb7b4fe1c8e4d0dac
