[gentoo-dev] profiles/base/make.defaults: add XDG_DATA_DIRS & XDG_CONFIG_DIRS to ENV_UNSET

[Pacho Ramos <pacho@gentoo.org>]

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

Hello,

This is a follow up from an older thread by leio in the mailing list:
https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9

The problem is that, at present time, we are getting more and more bugs
coming from flatpak users that get build failures due to having those
variables "polluted".

Personally, I would opt for unsetting them too and properly set them to
known values for packages needing it. But I am unsure if we could
probably do a tinderbox run to find&fix packages needing them to be set
:-/

I copy and paste here the original mail from leio as he was explaining
better the issue:
------------
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
------------

Thanks a lot for your thoughts

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