I am unable to successfully install `dev-libs/glib` into a different ROOT from a lightweight build container without `dev-libs/glib` installed. `gnome2_giomodule_cache_update` fails to run for amd64: ``` # emerge --root=/tmp/test dev-libs/glib --verbose * abi_x86_64.amd64: running multilib_pkg_postinst * Updating GIO modules cache ... /tmp/test/usr/bin/x86_64-pc-linux-gnu-gio-querymodules: error while loading shared libraries: libgmodule-2.0.so.0: cannot open shared object file: No such file or directory # find / -type f -iname '*libgmodule*' /tmp/test/usr/lib64/libgmodule-2.0.so.0.7600.3 ``` Reproducible: Always Steps to Reproduce: 1. Install Kubler (see wiki; ebuild development) 2. Run up an interactive builder 3. emerge --root=/tmp/test dev-libs/glib --verbose note; kubler has `--quiet-build` in the emerge default args
Created attachment 865770 [details] failing emerge in container
Created attachment 865771 [details] successful emerge in container
wait, is it running before ldconfig or something so the symlinked lib doesn't exist yet?
The function skips the cache update when cross-compiling (${CBUILD} != ${CHOST}). Calling binaries from ${ROOT} is probably a bad idea, regardless of whether we are cross-compiling. The runtime linker will always try to load libraries from ${BROOT}, which will lead to conflicts like this one.
This is an interesting one. If I recall correctly, the command has to run in the actual ROOT because it fully regenerates the cache and simultaneously depends on plugins you've installed. If you run without the plugins, that's not very good. But the plugins may be for files other than the ones you just installed. IDEPEND isn't a good fit for this as a) you can uninstall them, b) you might use a different BROOT to perform updates and the IDEPEND for some random other package isn't installed... I think the conservative choice is to skip doing anything when ROOT != BROOT. For bonus points we'd probably want to follow up by making this actually work, by chrooting in to run the command. Of course that would still need to guard against cross compiling, but it's still partial coverage of ROOT, which is better than *only* working via option 1.
Should we be trying to update it with the BROOT tooling if possible? Haven't really thought about the specifics yet myself, just throwing it out there for consideration
