| 1 |
Hello, |
| 2 |
|
| 3 |
Unlike most other XDG base directories[1], we do not do anything with |
| 4 |
XDG_DATA_DIRS - not in xdg_environment_reset, nor in ENV_UNSET. |
| 5 |
|
| 6 |
This is now causing some issues. |
| 7 |
|
| 8 |
Historically there was an issue[2] where a package added XDG_DATA_DIRS |
| 9 |
via env.d, which meant that if the base package (x11-misc/xdg-utils) |
| 10 |
wasn't yet installed, XDG_DATA_DIRS was set, but did not include the |
| 11 |
default paths, which broke some things as demonstrated there. |
| 12 |
|
| 13 |
Now there is an issue[3] where another package prepends other paths, |
| 14 |
which are not accessible when sandboxed and some tests are trying to |
| 15 |
access them. In my case, I'm now hitting this with flatpak, which |
| 16 |
prepends these paths via profile.d instead (and does have correct |
| 17 |
handling of the default dirs if XDG_DATA_DIRS was previously unset). |
| 18 |
|
| 19 |
This is a fundamental thing, so just unsetting it only in that package |
| 20 |
feels rather incomplete. |
| 21 |
I would think that the correct fix would be add XDG_DATA_DIRS to |
| 22 |
ENV_UNSET and also unsetting it in xdg_environment_reset (for the |
| 23 |
benefit of older EAPIs), but I fear that in some cases we specifically |
| 24 |
do need it to see what variables are in there. Perhaps prefix. If |
| 25 |
that's the case, per-ebuild unsetting could be problematic for those |
| 26 |
cases as well. |
| 27 |
|
| 28 |
Or is there some way to avoid such use cases of XDG_DATA_DIRS additions |
| 29 |
to not reach the portage environment in the first place? |
| 30 |
|
| 31 |
|
| 32 |
Thoughts? |
| 33 |
|
| 34 |
|
| 35 |
Mart |
| 36 |
|
| 37 |
1. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html |
| 38 |
2. https://bugs.gentoo.org/635040 |
| 39 |
3. https://bugs.gentoo.org/701978 |
Archives