emerge seems do not use PORTAGE_CONFIGROOT variable to evaluate dependencies. Reproducible: Always Steps to Reproduce: 1. PORTAGE_CONFIGROOT=/mnt/chroot/udoo ROOT=/mnt/chroot/udoo SYSROOT=/mnt/chroot/udoo nohup emerge @system --autounmask-write y Actual Results: s939 ~ # ls -l /etc/portage/package.keywords/ -lAt|grep cfg -rw-r--r-- 1 root root 775 26 dic 21.52 ._cfg0000_zzz the ouptut ._cfg* file is putted in /etc/portage, instead of ${PORTAGE_CONFIGROOT}/etc/portage
Created attachment 392476 [details] emerge info
Created attachment 392478 [details] output of strace, during emerge doing: PORTAGE_CONFIGROOT=/mnt/chroot/udoo ROOT=/mnt/chroot/udoo SYSROOT=/mnt/chroot/udoo nohup strace -f -eopen emerge @system --autounmask-write y |& grep "\/etc\/portage" >strace.txt & this shows that emerge looks at /etc/portage, instead of ${PORTAGE_CONFIGROOT}/etc/portage to evaluate dependencies.
Thank's for your attention. I see you handle my bug as a autounmask issue. Please check if the problem may it be more severe, and if it depends from a bad behaviuour of emerge. Indeed, the strace log I've attached show that emerge scans /etc/portage packages.use, /etc/portage/package.keywords and so on, looking for dependency settings. That's a severely wrong behaviuor, because the user needs to scan ${PORTAGE_CONFIGS}/etc/portage tree for own purposes. This may cause the complete impossibility, for the user, to obtain a coeherent system in crossdev ${ROOT}, and shows that a major emerge feature is broken. Moreover, the bad autounmask behaviuor shows that emerge make write accesses on wrong places, creating a concrete danger for system integrity. if all that wolud be true, we have a critical bug, which blocks development and/or testing work of Gentoo as a whole. sorry, if this seems long too much. I'm not a developer and I don't know english very well. I hope this helps to avoid a possible understimate of my issue.
(In reply to Marco Clocchiatti from comment #2) > this shows that emerge looks at /etc/portage, instead of > ${PORTAGE_CONFIGROOT}/etc/portage to evaluate dependencies. It's designed to do that. Please see bug #261109, comment #4 for my explanation. *** This bug has been marked as a duplicate of bug 261109 ***
Note that you can use the --root-deps option to force all dependencies to be installed into $ROOT. Also, note that I've opened bug #533884 for some buggy behavior involving --autounmask-write, PORTAGE_CONFIGROOT, and CONFIG_PROTECT.
