<<< dir /usr/lib64/perl5/vendor_perl/5.24.0/Package --- !empty dir /usr/lib64/perl5/vendor_perl/5.24.0 * perl-module.eclass: You are calling perl-module_pkg_postrm outside the perl-core category. * ERROR: dev-perl/Package-Constants-0.60.0::gentoo failed (postrm phase): * This does not do anything; the call can be removed. * * Call stack: * ebuild.sh, line 124: Called pkg_postrm * environment, line 2468: Called perl-module_pkg_postrm * environment, line 2093: Called die * The specific snippet of code: How to reproduce: 1. Install a package in perl-core/ 2. pkgmove package to dev-perl/ 3. Uninstall package Reason: perl-module.eclass has this stanza in both EAPI5 and EAPI6: [[ ${CATEGORY} == perl-core ]] && \ PERL_EXPF+=" pkg_postinst pkg_postrm" This means when the ebuild is sourced, pkg_postrm is defined in its environment and calls perl-module_pkg_postrm As long as the package stays in $CATEGORY == perl-core, nothing bad happens: perl-module_pkg_postrm() { debug-print-function $FUNCNAME "$@" if [[ ${CATEGORY} != perl-core ]] ; then eerror "perl-module.eclass: You are calling perl-module_pkg_postrm outside the perl-core category." die " This does not do anything; the call can be removed." fi perl_link_duallife_scripts } However, this function stays in place when the package is pkgmoved while installed.... And this means $CATEGORY changes. So subsequently, uninstalling a package after a pkgmove invokes the embedded environment, calls its pkg_postrm, calls perl-module_pkg_postrm, the if statement then becomes TRUE, and then an error is invoked and the code dies. Dying in pkg_postrm considered harmful regardless of where you use it ...
