From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Darrington Subject: Re: [PATCH 1/4] gnu: Add XFILESEARCH path to profiles' environment. Date: Mon, 28 Nov 2016 14:19:26 +0100 Message-ID: <20161128131926.GA6466@jocasta.intra> References: <1480100924-23868-1-git-send-email-jmd@gnu.org> <87zikkk485.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBLqa-00025Q-8Q for guix-devel@gnu.org; Mon, 28 Nov 2016 08:19:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBLqW-0003fe-7M for guix-devel@gnu.org; Mon, 28 Nov 2016 08:19:52 -0500 Content-Disposition: inline In-Reply-To: <87zikkk485.fsf@gnu.org> 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: Ludovic Court??s Cc: guix-devel@gnu.org, John Darrington --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =20 > * gnu/system.scm (operating-system-etc-service): Add new environment variable: =20 The guix.texi change is missing from the log. Thanks for noticing. =20 > diff --git a/doc/guix.texi b/doc/guix.texi > index e64c361..9d133bb 100644 > --- a/doc/guix.texi > +++ b/doc/guix.texi > @@ -1209,6 +1209,36 @@ data in the right format. > This is important because the locale data format used by different l= ibc > versions may be incompatible. > =20 > address@hidden X Window System > address@hidden XFILESEARCHPATH > address@hidden @code{Xt} > address@hidden X Toolkit Intrinsics > address@hidden @command{xterm} > + > +If you intend to use X Toolkit Intrinsics client applications such > +as @command{xterm} then you should define the @code{XFILESEARCHPATH} > +environment variable: > + > address@hidden > +$ export XFILESEARCHPATH=3D"$HOME/.guix-profile/share/X11/%L/%T/%N%C= %S: > + $HOME/.guix-profile/share/X11/%l/%T/%N%C%S: > + $HOME/.guix-profile/share/X11/%T/%N%C%S: > + $HOME/.guix-profile/share/X11/%L/%T/%N%S: > + $HOME/.guix-profile/share/X11/%l/%T/%N%S: > + $HOME/.guix-profile/share/X11/%T/%N%S: > + $HOME/.guix-profile/lib/X11/%L/%T/%N%C%S: > + $HOME/.guix-profile/lib/X11/%l/%T/%N%C%S: > + $HOME/.guix-profile/lib/X11/%T/%N%C%S: > + $HOME/.guix-profile/lib/X11/%L/%T/%N%S: > + $HOME/.guix-profile/lib/X11/%l/%T/%N%S: > + $HOME/.guix-profile/lib/X11/%T/%N%S" > address@hidden example =20 Seriously?! I mean, we can reasonably ask people to do that, can we? Is there another way? *shrug?* It's one more variable to set. Granted it's a long one. But it's not *us* that's asking them to do it. We are merely passing along advice =66rom the Xt lib developers (see below). If people want to use Xt then that's what they're supposed to do. We could do is to provide a script for the user to source or copy to her =2Eprofile =20 Naive approach to look for candidate variables: =20 --8<---------------cut here---------------start------------->8--- $ ltrace -e getenv xterm 2>&1 |grep '"X'|sort -u libX11.so.6->getenv("XCOMPOSECACHE") =3D nil libX11.so.6->getenv("XCOMPOSEFILE") =3D nil libX11.so.6->getenv("XKB_DEBUG") =3D nil libX11.so.6->getenv("XKB_DISABLE") =3D nil libX11.so.6->getenv("XKEYSYMDB") =3D nil libX11.so.6->getenv("XLIBBUFFERSIZE") =3D nil libX11.so.6->getenv("XLIB_SKIP_ARGB_VISUALS") =3D nil libX11.so.6->getenv("XLOCALEDIR") =3D nil libX11.so.6->getenv("XMODIFIERS") =3D nil libXau.so.6->getenv("XAUTHORITY") =3D "/home/ludo/.Xauth= ority" libXt.so.6->getenv("XAPPLRESDIR") =3D nil libXt.so.6->getenv("XENVIRONMENT") =3D nil libXt.so.6->getenv("XFILESEARCHPATH") =3D nil libXt.so.6->getenv("XTAPPPEEKEVENT_SKIPTIMER") =3D nil libXt.so.6->getenv("XUSERFILESEARCHPATH") =3D nil --8<---------------cut here---------------end--------------->8--- =20 Would one of these work better? :-) No. See below. > +export XFILESEARCHPATH=3D\"$HOME/.guix-profile/share/X11/%L/%T/%N%C%= S:\\ > +$HOME/.guix-profile/share/X11/%l/%T/%N%C%S:\\ > +$HOME/.guix-profile/share/X11/%T/%N%C%S:\\ > +$HOME/.guix-profile/share/X11/%L/%T/%N%S:\\ > +$HOME/.guix-profile/share/X11/%l/%T/%N%S:\\ > +$HOME/.guix-profile/share/X11/%T/%N%S:\\ > +$HOME/.guix-profile/lib/X11/%L/%T/%N%C%S:\\ > +$HOME/.guix-profile/lib/X11/%l/%T/%N%C%S:\\ > +$HOME/.guix-profile/lib/X11/%T/%N%C%S:\\ > +$HOME/.guix-profile/lib/X11/%L/%T/%N%S:\\ > +$HOME/.guix-profile/lib/X11/%l/%T/%N%S:\\ > +$HOME/.guix-profile/lib/X11/%T/%N%S:\\ > +/run/current-system/profile/share/X11/%L/%T/%N%C%S:\\ > +/run/current-system/profile/share/X11/%l/%T/%N%C%S:\\ > +/run/current-system/profile/share/X11/%T/%N%C%S:\\ > +/run/current-system/profile/share/X11/%L/%T/%N%S:\\ > +/run/current-system/profile/share/X11/%l/%T/%N%S:\\ > +/run/current-system/profile/share/X11/%T/%N%S:\\ > +/run/current-system/profile/lib/X11/%L/%T/%N%C%S:\\ > +/run/current-system/profile/lib/X11/%l/%T/%N%C%S:\\ > +/run/current-system/profile/lib/X11/%T/%N%C%S:\\ > +/run/current-system/profile/lib/X11/%L/%T/%N%S:\\ > +/run/current-system/profile/lib/X11/%l/%T/%N%S:\\ > +/run/current-system/profile/lib/X11/%T/%N%S\" =20 That=E2=80=99s unreasonable IMO. This is merely the default value that the Xt library sets, but I have simply substituted "/usr" with "$HOME/.guix-profile" and repeated it substituting "/run/current-system/profile". It is a large string, but why is that a problem? We can cut down on the size of this string iff we can somehow guarantee that no package ever ships a file in any of those locations. Some "solutions" (in my order of preference) are: * The size of the above list can be halved, by dropping either the =2E../lib/... or the .../share/... items - we just have to then make sure that no package ships resource files in the one we drop. Historically, resource files were always in .../lib (as still are all official sources from x.org) but recently third party packages have started putting them in .../share. * I *think* we could also get away with further reducing the set to=20 "$HOME/.guix-profile/lib/X11/%T/%N%S: /run/current-system/profile/lib/X11/%T/%N%S" because, all the Xt dependent packages I've seen so far, put their resource files there. However, we cannot know what might get added in the future. * Hack the hard coded defaults in the libXt source to use the profile settings instead of /usr * Do what we had before: Wrap *every* program which uses libXt in a script setting XAPPLRESDIR - This is sure to annoy users because it would override any XUSERFILESEARCHPATH they had set themselves. =20 Is this motivated by the broken ctrl-click in xterm? That thing used to work, I wonder what happened. Xterm has never worked properly for me under GuixSD. It "worked" under Guix on Debian, presumably because it found the resource files from the native installation. Xterm not working was what prompted me to find out the cause. But it will affect all and every package which provides X resource files as a shipped file. Anyway my general opinion is, that I agree that the value of this variable is rather long, but: 1. I don't see why that is a problem. 2. It is how the X Consortium intends and recommends it to be used. 3. A competent user will not be intimidated by it. 4. A naive user will never be aware of it anyway. For background information, see: * http://www.faqs.org/faqs/Xt-FAQ * The man page for XtResolvePathname * The file specs/CH11.xml in the libXt source. J' --=20 Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3=20 fingerprint =3D 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlg8Lt4ACgkQimdxnC3oJ7MQpQCeOdS7AGRnbLfYop6ZUDu7WZ5Y BKoAoIhCgv525Qg3rOSMwuCUBwKOLsNV =xMc0 -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v--