After portage update when trying to rebuild my custom EAPI="0" packages (from my overlay), the build fails in install phase on QA abort. Relevant parts of build process: /usr/lib/portage/python3.10/misc-functions.sh: line 85: local: ED: readonly variable * QA Notice: / installed in ${ED}/${D} * QA Notice: /opt installed in ${ED}/${D} * QA Notice: <truncated for privacy, but it lists entire content of ${PORTAGE_BUILDDIR}/image> * ERROR: category/package-1.0.0::overlay failed: * Aborting due to QA concerns: files installed in //home/portage/var/tmp/portage/portage/category/package-1.0.0/image/ * * Call stack: * misc-functions.sh, line 670: Called install_qa_check * misc-functions.sh, line 134: Called source 'install_symlink_html_docs' * 05prefix, line 114: Called install_qa_check_prefix * 05prefix, line 11: Called die * The specific snippet of code: * die "Aborting due to QA concerns: files installed in ${ED}/${D}" When I set the EAPI="4" on my custom package, problem disappears (along with the error on the first line of my log above). What I've found out: - In EAPI 0, ${ED} variable did not existed (was introduced with EAPI 3 or 4). - In file /usr/lib/portage/python3.10/misc-functions.sh on line 85: is trying to copy ${D} into ${ED}, which fails as read only variable. - install-qa-check.d/05prefix uses the variable ${ED} which is empty (because it was read only) - tested by manually adding eqawarn into 05prefix to print contents of ${D} and ${ED} I have sys-apps/portage version 3.0.37
Yes, indeed a real issue, although I think it's somewhat brave to continue using EAPI 0 given clearly nobody is testing these codepaths anymore. Is there a reason you are?
Perhaps we should simply start removing support for old EAPIs from Portage. There's very little value in keeping them, and even less in putting an effort to fix them.
(In reply to Sam James from comment #1) > Yes, indeed a real issue, although I think it's somewhat brave to continue > using EAPI 0 given clearly nobody is testing these codepaths anymore. Is > there a reason you are? Actually, this ebuild is pretty old, but is still doing its job satisfactory and there were no need to do a new ebuild just to bump EAPI... At least not for now. We have around 100 of those old packages in our overlay. But given that there were another EAPI 0 issue not long ago (Gentoo bug #869182), those codepaths are beginning to break down. (In reply to Michał Górny from comment #2) > Perhaps we should simply start removing support for old EAPIs from Portage. > There's very little value in keeping them, and even less in putting an > effort to fix them. I agree that removing old EAPIs can improve this situation in the long run (given the fact that those codepaths are not that well tested and it just complicates the code for Portage scripts such as QA). It will be easier to debug/prevent these kind of issues if the Portage just reports unsupported EAPI instead of just crashing the merge somewhere deep in QA scripts. And it would also be good when old EAPIs are removed if Portage could then report packages that have no ebuild with satisfactory EAPI (similar to "all suitable packages satisfying XY are masked").
