When emerging a package using ROOT="/newroot", it can fail with the message "Unable to resolve <package> to an installed package" when calling built_with_use, because it only checks for the package in /newroot having been built with that USE flag, not the package in /. For example, I was trying to emerge splashutils using ROOT="/newroot" and got the following: splashutils-1.3-r1.ebuild, line 77: Called built_with_use 'sys-devel/gcc' 'vanilla' ... !!! Unable to resolve sys-devel/gcc to an installed package This failed because I don't have gcc installed in /newroot, but I obviously have it installed in /. Splashutils installs fine if that check is removed. I'm not sure how I'd suggest this should be fixed - I think ideally it would check packages in / for DEPEND, and in /newroot for RDEPEND, but I'm not even convinced that is foolproof in all circumstances.
built_with_use uses the $ROOT variable, so the ebuild should override that variable just for the built_with_use call. Example: if ROOT=/ built_with_use sys-devel/gcc vanilla ; then ewarn "Your GCC was built with the 'vanilla' flag set." fi
Of course, the example shown in comment #1 will only work in the simplest of cases. It won't work correctly if there are multiple versions of gcc installed or a cross-toolchain is being used. It seems like we need a function (maybe in toolchain-func.eclass or something) the maps the currently selected compiler back to the exact package that provides it.
it isnt just a compiler issue, it's any DEPEND atom i dont think this can be fixed as the real fix here is to implement USE depends
(In reply to comment #3) > it isnt just a compiler issue, it's any DEPEND atom Fair enough. > i dont think this can be fixed as the real fix here is to implement USE depends If the package use-deps on a specific compiler, how can it ensure the correct compiler is selected at build time though? That type of requirement doesn't fit any of the existing *DEPEND, and would require a new type or at least a syntax extension.
hmm, so we have two issues at hand ... the ROOT/DEPEND requires proper syntax for declaring USE in DEPEND atoms not sure if it is feasible to query portage about the capabilities of the compiler as that shouldnt be something you should need to do ... consider the case where someone installs and uses a compiler external to portage ... there are certainly plenty of compilers out there that we do not have ebuilds for
Any news on this issue? I've just encountered similar problem when emerged *-9999.ebuild (SVN) to different ROOT: * Call stack: * ebuild.sh, line 48: Called src_unpack * environment, line 2145: Called subversion_src_unpack * environment, line 2411: Called subversion_fetch * environment, line 2278: Called built_with_use '-o' 'dev-util/subversion' 'webdav-neon' 'webdav-serf' * environment, line 209: Called die * The specific snippet of code: * [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"; * The die message: * Unable to resolve dev-util/subversion to an installed package My base system contains subversion, but ROOT doesn't.
in EAPI 5, has_version supports --host-root option to do this, and built_with_use is deprecated (or not supported?). ebuilds/eclasses that use this incorrectly should have bugs filed against them (for example, I think subversion.eclass should use it).
