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.
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.
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.