Hello, Unlike most other XDG base directories[1], we do not do anything with XDG_DATA_DIRS - not in xdg_environment_reset, nor in ENV_UNSET.
This is now causing some issues. Historically there was an issue[2] where a package added XDG_DATA_DIRS via env.d, which meant that if the base package (x11-misc/xdg-utils) wasn't yet installed, XDG_DATA_DIRS was set, but did not include the default paths, which broke some things as demonstrated there. Now there is an issue[3] where another package prepends other paths, which are not accessible when sandboxed and some tests are trying to access them. In my case, I'm now hitting this with flatpak, which prepends these paths via profile.d instead (and does have correct handling of the default dirs if XDG_DATA_DIRS was previously unset). This is a fundamental thing, so just unsetting it only in that package feels rather incomplete. I would think that the correct fix would be add XDG_DATA_DIRS to ENV_UNSET and also unsetting it in xdg_environment_reset (for the benefit of older EAPIs), but I fear that in some cases we specifically do need it to see what variables are in there. Perhaps prefix. If that's the case, per-ebuild unsetting could be problematic for those cases as well. Or is there some way to avoid such use cases of XDG_DATA_DIRS additions to not reach the portage environment in the first place? Thoughts? Mart 1. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html 2. https://bugs.gentoo.org/635040 3. https://bugs.gentoo.org/701978
signature.asc
Description: This is a digitally signed message part
