That's a chicken and egg issue. This little snippet of code env -u DISTDIR \ -u PORTAGE_OVERRIDE_EPREFIX \ -u PORTAGE_REPOSITORIES \ -u PORTDIR \ -u PORTDIR_OVERLAY \ PYTHONPATH="${ED%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" \ "${PYTHON}" -m portage._compat_upgrade.default_locations || die in portage 2.3.64 ebuild will always fail because default_location.py does not exist in previous version of portage. Reproducible: Always Steps to Reproduce: 1.sudo emerge portage (I got 2.3.63 installed at the time) Actual Results: * ERROR: sys-apps/portage-2.3.64::gentoo failed (preinst phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called pkg_preinst * environment, line 3257: Called die * The specific snippet of code: * env -u DISTDIR -u PORTAGE_OVERRIDE_EPREFIX -u PORTAGE_REPOSITORIES -u PORTDIR -u PORTDIR_OVERLAY PYTHONPATH="${ED%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" "${PYTHON}" -m portage._compat_upgrade.default_locations || die; WORKAROUND to install version 2.3.64 1) Remove offending "|| die" in portage ebuild 2) emerge portage twice (first time portage will complain about missing module, second time will work)
However this code sets PYTHONPATH...
Maybe the PYTHONPATH="${ED%/}${PYTHON_SITEDIR}" setting is somehow incorrect.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3a95fc7560502ad7494862c49a4c0a0ed33c58b commit c3a95fc7560502ad7494862c49a4c0a0ed33c58b Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-04-22 07:02:01 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-22 07:14:39 +0000 sys-apps/portage: fix PYTHONPATH in pkg_postinst (bug 683932) Since PYTHON_SITEDIR begins with ${EPREFIX}, avoid a double prefix by using ${D} instead of ${ED}. Bug: https://bugs.gentoo.org/683932 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/portage-2.3.64.ebuild | 2 +- sys-apps/portage/portage-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
(In reply to Zac Medico from comment #2) > Maybe the PYTHONPATH="${ED%/}${PYTHON_SITEDIR}" setting is somehow incorrect. It could fail if python_setup selects a python interpreter that is not enabled in PYTHON_TARGETS for the current instance of portage that's being installed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cd42be9b33ca5b54a6429305acea8000bb268483 commit cd42be9b33ca5b54a6429305acea8000bb268483 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-04-22 21:36:15 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-22 21:36:21 +0000 sys-apps/portage: validate PYTHON_SITEDIR (bug 683932) Bug: https://bugs.gentoo.org/683932 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/portage-2.3.64.ebuild | 1 + sys-apps/portage/portage-9999.ebuild | 1 + 2 files changed, 2 insertions(+)
Please test the current ebuild which validates that ${D%/}${PYTHON_SITEDIR} exists.
(In reply to Zac Medico from comment #6) > Please test the current ebuild which validates that ${D%/}${PYTHON_SITEDIR} > exists. Still doesn't work but I found the issue. Problem is with python_export() function call which sets PYTHON_SITEDIR variable to /usr/lib/python3.7/site-packages on my system. If I add missing /local/ to the path, so using PYTHON_SITEDIR="/usr/local/lib/${EPYTHON}/site-packages" sys-apps/portage-2.3.64 install fine, no complains. More oddities. This issue is only present if I upgrade from older portage releases. Re-installing portage 2.3.64 (on top of 2.3.64) works perfectly with the original unmodified ebuild.
No Python packages should install anything into /usr/local/... in Gentoo. You have done something to break your Python.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #8) > No Python packages should install anything into /usr/local/... in Gentoo. > You have done something to break your Python. I disagree because first I have no Python package in /usr/local/ in my system (/usr/local point to /usr with a symlink) and as far I remember (10 years+) I never had any issue with any Python 2.x/3.x packages (or others) complaining about that. BTW, I don't really care too much about that bug because I consider it as a glitch. If I can reinstall version 2.3.64 with an unmodified ebuild (which works) it should succeed as well on any portage future releases.
