From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mikhail Kryshen Subject: Re: qt-build-system: prefix or suffix env-variables in wrap-program Date: Tue, 17 Dec 2019 19:56:21 +0300 Message-ID: <87fthidh6y.fsf@e6230.localdomain> References: <2dd04e9b-2988-6415-c7ec-df4a6ef91920@crazy-compilers.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58289) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihG9A-0003PW-Ro for guix-devel@gnu.org; Tue, 17 Dec 2019 11:56:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihG98-0007Ki-SV for guix-devel@gnu.org; Tue, 17 Dec 2019 11:56:32 -0500 Received: from mail.kryshen.net ([31.220.44.128]:50258) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ihG98-0007DU-Mh for guix-devel@gnu.org; Tue, 17 Dec 2019 11:56:30 -0500 In-Reply-To: <2dd04e9b-2988-6415-c7ec-df4a6ef91920@crazy-compilers.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Hartmut Goebel , Guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for the late reply. Hartmut Goebel writes: > Am 11.12.19 um 21:25 schrieb Mikhail Kryshen: >> So the correct way to extend XDG_DATA_DIRS would be >> >> export XDG_DATA_DIRS=3D"${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/= }:/gnu/store/=E2=80=A6-kate-=E2=80=A6" > > I'm quite confident, adding /usr/share etc. here as default would be > wrong from a guix point of view: This would break isolation of > environments. On a foreign distribution this would even give the foreign > distribution's installation precedence over guix's. The problem is that conforming programs treat empty or unset XDG_DATA_DIRS as "/usr/local/share/:/usr/share/", for such programs XDG_DATA_DIRS=3D"" and XDG_DATA_DIRS=3D"/usr/local/share/:/usr/share/" are equivalent, and thus their extensions should be equivalent too. Empty or unset XDG_DATA_DIRS already breaks isolation: when it is empty, it means (according to the spec) that programs are supposed to refer to /usr in the current environment. Because of this, I think that in pure Guix environment XDG_*_DIRS variables should never be left unset (and so /usr will not be referred to implicitly and will not appear in the extended value). Overriding the value (including the implicit "/usr/local/share/:/usr/share/") will cause problems when wrapped program launches a non-guix program from the host system (e.g. MUA opening an attachment) that will inherit its environment. > Anyway: Let me ask my question differently: Should the user be able to > *overrule* or only to *extend* guix's installation? Allowing to overrule will be problematic, because XDG_*_DIRS may be set by the system and include directories with conflicting files (e.g. from different version of the same program installed in the system profile or in the host non-guix system). So I suggest prefixing XDG_*_DIRS like this: XDG_DATA_DIRS=3D"/gnu/store/=E2=80=A6:${XDG_DATA_DIRS:-/usr/local/share/:= /usr/share/}" So the added path gets higher priority, and the other paths are preserved, including the implicit "/usr/local/share/:/usr/share/" in case of initially empty variable. =2D- Mikhail --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEw6yVFU/UQfkLWikDzxz0c4HWsG4FAl35CLUACgkQzxz0c4HW sG582gv+Pp0pgI2dhXKwnc633YKPRXxrVGgp3SH9UGdOSiY3eVBeSmGPkCipzv9y DE8oVE/Pbo6xtX8bF9z9AQie+qGYWVqrKwg4CV+uo5GVak5Z0Dt8w6ftLr0eZMzu oaaYh0ZI7Kjwcunp6jtx61g90qH/yrX4Q6befOHy2ozCYJpI24aMuY3ekDL6MNtg 0X6t1I5/lWl0EZhtQjNV5DxxGPUU4j7cQMdud+s97oNYg+gzZnFQ3rntOKaXHxQq 5YQO0W+buZkyIe5fQ81/GB5qQlYbwn7qzixgGWNxELQWEGW4MFYWdHqiyiylT4DW 8p8bci2KewcBND7kdTg2RUFUwNmTMt1uet/S59HFU1k63X/iY+67VV+JcmgJzhXJ Vrvwy+h+JWfs5rOOIRp+QqG+yXYFbqppjXOZkDRIZlyyfLUyMeF+z0N1nFDFqufz toBTYeKf9gt06Db40KRnIGHypSE3RTZHJrkq/WvhQcpRciHUSKDG4zDRVg9tZB9N Q1vqFJVQ =4zdF -----END PGP SIGNATURE----- --=-=-=--