When I emerge CDDB_get there is a shell script error which causes the install to fail. Emerge runs to completion normally but the package is not installed properly. Reproducible: Always Steps to Reproduce: 1. emerge -v CDDB_get 2. 3. Actual Results: /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment: line 345: pushd: /var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8: No such file or directory Expected Results: I expect the install to complete normally. # emerge -v CDDB_get These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-perl/CDDB_get-2.27 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-perl/CDDB_get-2.27 * CDDB_get-2.27.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking CDDB_get-2.27.tar.gz to /var/tmp/portage/dev-perl/CDDB_get-2.27/work /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment: line 345: pushd: /var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8: No such file or directory /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment: line 385: popd: directory stack empty find: `/var/tmp/portage/dev-perl/CDDB_get-2.27/work/CDDB_get-3.2.8': No such file or directory >>> Source unpacked in /var/tmp/portage/dev-perl/CDDB_get-2.27/work >>> Compiling source in /var/tmp/portage/dev-perl/CDDB_get-2.27/work ... * No Make or Build file detected... >>> Source compiled. >>> Test phase [not enabled]: dev-perl/CDDB_get-2.27 >>> Install CDDB_get-2.27 into /var/tmp/portage/dev-perl/CDDB_get-2.27/image/ category dev-perl >>> Completed installing CDDB_get-2.27 into /var/tmp/portage/dev-perl/CDDB_get-2.27/image/ >>> Installing (1 of 1) dev-perl/CDDB_get-2.27 * checking 0 files for package collisions >>> Merging dev-perl/CDDB_get-2.27 to / >>> Safely unmerging already-installed instance... No package files given... Grabbing a set. >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. >>> dev-perl/CDDB_get-2.27 merged. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date.
Looks like something polluted the environment. :) Could you attach the environment file, please? /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment
Also, please post your `emerge --info' output. Looking for anything with version 3.2.8, I guess the most likely candidate for a recent upgrade was sys-process/procps-3.2.8_p11, which does set the S variable to ${WORKDIR}/${PN}-${MY_PV}.
Created attachment 292849 [details] Output of 'emerge --info' on affected system. I have attached the output of 'emerge --info' as a file. There is no file /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment on my system. Is it a temporary file that gets removed after emerge completes? How can I capture it?
(In reply to comment #3) > Created attachment 292849 [details] > Output of 'emerge --info' on affected system. > > I have attached the output of 'emerge --info' as a file. There is no file > /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment on my system. Is it a > temporary file that gets removed after emerge completes? How can I capture it? It's created while the package is being compiled. It's left along with all the work files when emerge fails, so it should be there somewhere.
Created attachment 292943 [details] /var/tmp/portage/dev-perl/CDDB_get-2.27/temp/environment Here is the environment file, as an attachment. emerge is not trapping the shell script error so it completes normally, cleans up after itself, and remove /var/tmp/portage/dev-perl/CDDB_get-2.27/, exiting with a return code of 0. I had to run ebuild manually through the unpack phase to get this file.
Looks like this time the environment was not polluted.
Since the pushed failure occurs during src_unpack, base_src_unpack from base.eclass (not a portage internal) seems a likely candidate: base_src_unpack () { debug-print-function $FUNCNAME "$@"; pushd "${WORKDIR}" > /dev/null; [[ -n "${A}" ]] && unpack ${A}; has src_prepare ${BASE_EXPF} || base_src_prepare; popd > /dev/null }
i don't think base-system has ever touched base.eclass. sending to @MAINTAINER listed in it ...
I guess it is caused by: | declare -x MODULE_VERSION="3.2.8" Where do these variables come from? MODULEPATH="/usr/local/Modules/versions:/usr/local/Modules/\$MODULE_VERSION/modulefiles:/usr/local/Modules/modulefiles" MODULESHOME="/usr/local/Modules/3.2.8" declare -x MODULE_VERSION="3.2.8" declare -x MODULE_VERSION_STACK="3.2.8"
Those variables come from my environment. I have program called Modules installed which sets them. (http://modules.sourceforge.net/)
Anything we should do to prevent the collision of the perl-module.eclass variable MODULE_VERSION and the Modules env var MODULE_VERSION?
(In reply to Torsten Veller (RETIRED) from comment #11) > Anything we should do to prevent the collision of the perl-module.eclass > variable MODULE_VERSION and the Modules env var MODULE_VERSION? Don't think we can do much here.
