From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A4952139360 for ; Fri, 13 Aug 2021 07:17:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A7371E0855; Fri, 13 Aug 2021 07:17:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 99C0AE0841 for ; Fri, 13 Aug 2021 07:17:12 +0000 (UTC) Message-ID: <583ad64b1334e59806e784525f3e2cd30429313c.camel@gentoo.org> Subject: [gentoo-dev] XDG_DATA_DIRS handling under packages From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Fri, 13 Aug 2021 10:17:07 +0300 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-I93yhCn1LEGJOtQU51g2" User-Agent: Evolution 3.40.3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 9eefc7aa-538a-4b83-842b-c6d8735843d5 X-Archives-Hash: bf36c4c50f9c15db222faa6a66b0c6c9 --=-I93yhCn1LEGJOtQU51g2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 --=-I93yhCn1LEGJOtQU51g2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAmEWHHNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgYpBw/9EtfZSONbRrFDsCMcq9h7S+CePuvzfg1oJ5nHwPutMkvvhrxQQDGjVvEa fgFLeJ6WbLLDZ5eych3HQL4sjGiE8R3wgwkViRMFGD4isk2eAFieLv44siAQ3w82 d+bF2PIrK0Hfrplkv+DtKPTteiGn3IboDyKCBk5cbvuYlGjGaVm4djqvy3iud+cU FeaQzcjISC3X8WKe9SMCvX9i54D47ov4lAkAQm4UtyqgGVipOXqZIgiBSvNqPE0E 29Y2CuL5LEEav2HnOGibBOfiwdokx7FMsrej/AWv2IWoKDDDI64/tOQ0jWzu9JeQ 9lnRqgbtAG9u8wzNd1o6ctWU25SClFIS2D9sVrNhiOwbB7wGRP+xUoz2QGOPRxit k6TWbQnxTXjqkKuHy2K6dtsiNXEArm35NnQ3NGmG69o1OgQnJe6zRm4KJO8r3dUu OqmoDv11e4OX5WKOy06FEbZHnMVYWI4NJp/TRoGyl2i6zYJ1HHKr/6huidyFaeEF AGGtzvx3tG7t7gDufDLhKB78hco7pbkfv2kGQqu+LvY9KSJZYaqG49xrtfeJoSnk BCacaUc5i8Yv4GHLFcxm0PriSOSbh7kCmhSjkxpEaL/p1/lcHFEX4v4xuRRipWGc iS1g4phnm1dL58HULT+/OnYTlC+QYe/bsKjjyPAd3bCi9JQ8Ft8= =oE62 -----END PGP SIGNATURE----- --=-I93yhCn1LEGJOtQU51g2--