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

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

[Pacho Ramos]

[-- 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 --]

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

[Mike Gilbert]

On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos <pacho@gentoo.org> wrote:
>
> 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'm not really familiar with the packages that require these
variables. I agree with the idea in principle though.

It seems like x11-libs/gtk+ is one example given by leio. How would we
fix that one? Can the same strategy be applied to similar ebuilds?

Another possible idea would be to source /etc/profile.env in a
subshell and pick out the relevant XDG variables in
xdg_environment_reset.