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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9FC67158170 for ; Wed, 17 Jul 2024 18:57:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 57F20E2BC2; Wed, 17 Jul 2024 18:57:08 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B8941E2B65 for ; Wed, 17 Jul 2024 18:57:07 +0000 (UTC) Message-ID: <74b03b9eb4be6825a1c21d3fe828b3cf16843ff3.camel@gentoo.org> Subject: [gentoo-dev] profiles/base/make.defaults: add XDG_DATA_DIRS & XDG_CONFIG_DIRS to ENV_UNSET From: Pacho Ramos To: gentoo-dev@lists.gentoo.org Cc: Mart Raudsepp , Mike Gilbert Date: Wed, 17 Jul 2024 20:57:01 +0200 Autocrypt: addr=pacho@gentoo.org; prefer-encrypt=mutual; keydata=mQENBFs6a0cBCADdj1TWHYu2vOKe2d7KLTM43xfGB+ETM2F0T1xf7mGK3H8AFWxfw9dFk QsYmzlQ80ie3KLzrhN0hsRSJnmR00EVChjcnHA8SIDL3kyveTnrPAJry4bRJUaG3GMOa837YeoD9M MZYhE/LjrUY9oRS2bdFLWgP2LhBkGbeUifRddKyO21eyfGNqpUPb69K2OmIKalO2asjtUii+Jtmkm vyRsyurPLz2Fj+WkdgebWguVZYitB5fDB6ERVsmKd0f/a5Z4O2ZQI+akk+WyG6RsLIDHBEyx3/omS +GVx4fyoqzYRwXcmrNT425711x39+iLkj5noug3NCBpo5fg6tYSI9pM9ABEBAAG0KkZyYW5jaXNjb yBSYW1vcyBbcGFjaG9dIDxwYWNob0BnZW50b28ub3JnPokBVwQTAQgAQQIbAwULCQgHAwUVCgkICw UWAgMBAAIeAQIXgAIZARYhBEHIr3hZFZh/8ZIFg5nL3pYCUQ6xBQJi54s6BQkMT6XzAAoJEJnL3pY CUQ6x8AsH/0EP5oZ4SexbPqvpHR2xH+GHOE4abuapPSTTIQm/+Fh6XWI3mEPxKBLhHawS4Lgq6oCe x2OXO8HOdXpQ/gpyyx/hyGpzECYbj2uuH9YraDWYGer2AoYrXAjewMaA3eeW1JRLtuYTo0KZt4WNF TjwDgNpGKtm65c3RFf0UccILZei/lLPe+p+Qy1dxiHXMkV5x6Guaty9Bw2Njb5qH7JQG/rrZkYouo xhiohPyzIS5khAHH1XvhEzkS5EBCjTjFHA5OQhwa2qlEnNCSbb34ZKJHOYub7SuxdG/uDr/0r/i2z +n9j7XcFRvyfp4+EG5T6+lDhzXvUCqpLwo+kE5Hre3WC0LkZyYW5jaXNjbyBSYW1vcyBbcGFjaG9d IDxwYWNob3JhbW9zQGdtYWlsLmNvbT6JAVQEEwEIAD4CGwMCHgECF4AFCwkIBwMFFQoJCAsFFgIDA QAWIQRByK94WRWYf/GSBYOZy96WAlEOsQUCYueLOgUJDE+l8wAKCRCZy96WAlEOsSqwCACHa2SNXt AfhknYoE6rucjj//Svb9eRDLU7g4vx+P8re9VIGBJm1nXVake5WbSMKPVGHbCMRtz4G77bsF41Iin ut/+xh0e/BH2vpFvTgCUIZEDCnV9V21wsOe6vhUYjX6Q8Kd51hPPNfXsTRBSe0jZvnfvUZkovsa4X +f97qPiwKesyEYv9B3FBRe0fXRjFTSG+eHSOJZr60nIaVwvwtGOhMeg2mrKBcT+JhnS/RvoDk8CDw JNz+zqnUn8XeARmJRSjRhWClpcVMEqYu9BqP7/UAusQAvmgVNc1MfzbD8pgwsLksVWgrPoWeyHtW5 iAGpxXRp7SpA4+iqaLKvSBhiIgtB5QYWNobyBSYW1vcyA8cGFjaG9AZ2VudG9vLm9yZz6JAVQEEwE IAD4CGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQRByK94WRWYf/GSBYOZy96WAlEOsQUCYueL OgUJDE+l8wAKCRCZy96WAlEOsejCCACGBQO9+/oOOxU0ssEdtE4lDs6VZFiMIYOzN6RXiY41Qdj19 GjUoS4gr+Xcqwn3bS60OZ77d4kvl7ScmjdnHhW1jkPgKETixX1oQEk7BvB8bXNAS5EFSPfRBvn2XQ yzRB2tkMXOc0UNZyhyBHxHtpwBQYagWhrEOGPD8q4cZlopTFtG94NKf/hKGV78RHKv53kq7ISmY0S uRMc3uqCE1DnTDvS6XFucvwxIndQ0PMMi67S1xIeSkeW5mUa28YKdkaZGv+2z5rI6qjXWPfOEOqpb inAsxtXXuufccdVpGJu4CKbxVUwOfPL7We6rTAJN4nzkNoxYqoNRWiUWUsIrYgPD Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-OC6TTqcd/c8zWFKRHqK4" User-Agent: Evolution 3.52.2 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: 082f8495-a8e4-4185-bbde-3d198bad2231 X-Archives-Hash: 88e54d520ae9ebfbcad2543839118699 --=-OC6TTqcd/c8zWFKRHqK4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, This is a follow up from an older thread by leio in the mailing list: https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0= c6c9 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.=C2=A0But 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.htm= l 2. https://bugs.gentoo.org/635040 3. https://bugs.gentoo.org/701978 ------------ Thanks a lot for your thoughts --=-OC6TTqcd/c8zWFKRHqK4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE808Ng0g83FMNupoifLEMIH/AfbwFAmaYE/0ACgkQfLEMIH/A fbxoDQf+IneXIWteH+WkyvhGUUMdy0SUBs6sqsi0NmTOejsunOfOBON1I3dgtQil RNRQp5TiLUvKq6SopcY25S91vtAst8OiUBDYkwtHy27OwHshRLUR2IAoqWOw8+oD 2/8HUxtRKWf7XaYt2O3xzN41HucyO09KcjAzGrqXaW05wVWcqkhjdsjJIPtLeltd cNrjiYhabovc0p1TD7Qgn0HzYz1sXW/K/QeUp4nKku2KfC4Wah9JDl2RYcmUGuD6 Q0MYaP3me8DA3bfwmJj0dafJ2HVUH+U1v/sfonqkPQ0oZBzWPpfwBShZUkIY1kdz WUPK1b9wPp2Mp44sCOORwyh4c6s85Q== =hQ0B -----END PGP SIGNATURE----- --=-OC6TTqcd/c8zWFKRHqK4--