Using variables in make.conf such as ROOT=${SYSROOT} and then defining SYSROOT: SYSROOT=/my/sys/root emerge world ROOT will not pick up the SYSROOT definition. I don't know if this is by design or a bug but I would find it very useful if portage could honor env. variables while processing make.conf
The last part of this [1] comment somewhat suggests that this is by design. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/package/ebuild/config.py;h=92e6c3fedd209963347d2ffe6e74d7534823e083;hb=HEAD#l365
Sorry for late reply, been really sick the last few days. The comment seems to indicate that but the reason seems a little vauge. There are benefites to actually pick upp env too so what is it that portage is afraid to pick up? It does seem thougth that if you place you env. var into $eroot/etc/profile.env, it picks that upp. How is this so much better/safer than picking up env. directly?
Been playing with adding variables into etc/profile.env and noticed a possible bug. The profile.env is read from env_d = getconfig(os.path.join(eroot, "etc", "profile.env"), which requires me to set ROOT I expected this to honor PORTAGE_CONFIGROOT which is ignored in this instance. Should not the env_d line read: env_d = getconfig(os.path.join(config_root, "etc", "profile.env"), or similar ?
ping?
(In reply to Joakim Tjernlund from comment #3) > Been playing with adding variables into etc/profile.env and noticed > a possible bug. The profile.env is read from > env_d = getconfig(os.path.join(eroot, "etc", "profile.env"), > which requires me to set ROOT It's common for packages in $ROOT to install files into etc/env.d though, and profile.env is generated from etc/env.d. Unfortunately, the split between ROOT and PORTAGE_CONFIGROOT is not always clear and unambiguous.
