The issue is the addition to PATH in /etc/env.d/99host. It causes breakages like the one I've added to this bug as a blocker. My approach from the baselayout side would be to drop the creation of /etc/env.d/99host for prefix systems (I don't see this as a meson bug), but I don't know what the ramifications of that are. Thoughts? William
I will drop the blocker because it turned out that this is an automagic dependency. This means the build system for the package in question needs to be fixed. However, I still think it is a concern that baselayout is adding paths on the host system to the environment inside a prefix. Thoughts? William
I think this bug is invalid. Having extra elements in PATH should not be harmful to ebuilds.
I want to turn this bug into more of a discussion. Adding host paths to a prefix can confuse build systems like the example bug I linked in See also. It is true that this flushed out an automagic dependency. However, I would like to know more about why baselayout adds host paths to prefix systems and if there is possibly a better way to do it so that emerging packages inside the prefix doesn't get confused between what it finds in the prefix vs what it finds on the host system.
the host paths are added because there's tools that cannot be provided by the prefix, this is in particular for things like prtconv or other system utilities that configure uses to determine what box one's running on. Others are utilities such as dmesg or top that you want to be able to use within the Prefix, but cannot be provided or requires root e.g. to setuid.
Host paths are intentionally added to allow prefix users access to binaries that cannot be provided by the prefix guest.
