Oh, nevermind, I just realized: We use antimagic as the implementation goo for PSEUDO_DISABLED.
So a call to os.popen() from a program which has PSEUDO_DISABLED set is going to think it's in antimagic mode. And suddenly, the trick is revealed: os.popen() is bypassing all the runqueue stuff which is trying to ensure that the environment is in a valid state. So if bitbake code calls os.popen(), it may behave weirdly, for the same reason that any other direct invocation of fork() or system() or whatnot would behave weirdly -- because bitbake is running with pseudo in a strange state. So I think the thing is: Because bitbake is running with PSEUDO_DISABLED, any child process that is not explicitly set to either enable or unload pseudo is going to be running under pseudo, with PSEUDO_DISABLED. And that means we need to ensure that PSEUDO_PREFIX stays set, because we need that even when pseudo is disabled. (It's used during some of the initial setup sanity checks.) -s -- Listen, get this. Nobody with a good compiler needs to be justified. _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto