[gentoo-dev] XDG_DATA_DIRS handling under packages

[Mart Raudsepp <leio@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]