I use the "module" system to manage my environment (modules.sourceforge.net). Part of the way module works is to set a handful of helpful environment variables, one of which is MODULE_VERSION. In my particular case, MODULE_VERSION is set to 3.2.10 Some (few in my experience) ebuilds appear to pull the MODULE_VERSION from the environment during the build process and chokes on missing directories. Unsetting the MODULE_VERSION environment variable invariably allows the ebuild to proceed. An example is cups-filters, with the end of the ebuild output shown below: * ERROR: net-print/cups-filters-1.0.43-r1::gentoo failed (prepare phase): * The source directory '/var/tmp/portage/net-print/cups-filters-1.0.43-r1/work/cups-filters-3.2.10' doesn't exist * * Call stack: * ebuild.sh, line 714: Called __ebuild_main 'prepare' * phase-functions.sh, line 955: Called __dyn_prepare * phase-functions.sh, line 369: Called die * The specific snippet of code: * die "The source directory '${S}' doesn't exist" * * If you need support, post the output of `emerge --info '=net-print/cups-filters-1.0.43-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=net-print/cups-filters-1.0.43-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/net-print/cups-filters-1.0.43-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-print/cups-filters-1.0.43-r1/temp/environment'. * Working directory: '/usr/lib64/portage/pym' * S: '/var/tmp/portage/net-print/cups-filters-1.0.43-r1/work/cups-filters-3.2.10' * Regenerating GNU info directory index... * Processed 159 info files. * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. Somewhere, the cups-filters-${MODULE_VERSION} string is used to set a folder name, which results in the error you see here. I've set this as minor since there is an easy enough workaround.
Namespace!
We can't predict what user defined variables can conflict with ours.
Context for the user: This variable is a control mechanism for perl-module.eclass, which is used in 1667 ebuilds in dev-perl/* And the presence of said variable serves as an override mechanism to specify a different internal version identifier(MODULE_VERSION) to the ebuild provided one (PV) so we can have a gentoo-friendly version on the ebuild, and a perl-friendly version internally. Thus, there's no way we can really solve this without modifying a very large amount of ebuilds in an arbitrary way with very little gain, which may simply later result in somebody else having a conflict. So the recommendation is that you make sure that value is not set somehow in portage ( maybe unset it in make.conf, not sure ). Ideally we'd have a way to tell portage to mask that variable being settable from the environment, but there's no such mechanism at this time that I'm aware of.
(In reply to Kent Fredric from comment #3) > Context for the user: > > This variable is a control mechanism for perl-module.eclass, which is used > in 1667 ebuilds in dev-perl/* > > And the presence of said variable serves as an override mechanism to specify > a different internal version identifier(MODULE_VERSION) to the ebuild > provided one (PV) so we can have a gentoo-friendly version on the ebuild, > and a perl-friendly version internally. > > Thus, there's no way we can really solve this without modifying a very large > amount of ebuilds in an arbitrary way with very little gain, which may > simply later result in somebody else having a conflict. > > So the recommendation is that you make sure that value is not set somehow in > portage ( maybe unset it in make.conf, not sure ). > > Ideally we'd have a way to tell portage to mask that variable being settable > from the environment, but there's no such mechanism at this time that I'm > aware of Thank you for taking the time to explain. It makes perfect sense to me not to 'fix' this now. I'll try some changes in the make.conf file to see if I can work around it permanently.
