GNU bug report logs - #75688
Replace wrapper scripts with search path value files in search-paths.d

Previous Next

Full log

View this message in rfc822 format

From: 宋文武 <iyzsong <at> envs.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 75688 <at> debbugs.gnu.org, 宋文武 <iyzsong <at> member.fsf.org>, Vivien Kraus <vivien <at> planete-kraus.eu>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: [bug#75688] [PATCH 0/2] Introduce GUIX_LIBRARY_PATH to replace harmful environment variables
Date: Tue, 21 Jan 2025 12:42:10 +0800

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hello,
>
> iyzsong <at> envs.net writes:
>
>> From: 宋文武 <iyzsong <at> member.fsf.org>
>>
>> Hello, we currently set many environment variables from search-paths, some can be harmful for
>> foreign system, which leading crash, eg: GDK_PIXBUF_MODULE_FILE, QT_PLUGIN_PATH, as reported in:
>>
>>  <https://issues.guix.gnu.org/53514>
>>  <https://issues.guix.gnu.org/75523>
>>  <https://issues.guix.gnu.org/73897>
>>
>> Instead of patch each software/library with its own environment variables (GUIX_GTK3_PATH, GUIX_QT_PLUGIN_PATH),
>> we can try patch all to calculate their from one GUIX_LIBRARY_PATH (default to ~/.guix-profile/lib), since the
>> problems mostly come from incompatible libraries ABI, so from "lib" construct its subdirectories should be enough.
>> eg:
>>   GTK3_PATH use: lib/gtk-3.0
>>   FCITX_ADDONS_DIRS use: lib/fcitx5
>
> Instead of reconstructing the paths from something like the suggested
> new GUIX_LIBRARY_PATH, I think it'd be nice if additionally to the stock
> environment variables supported by each software, we introduced GUIX_
> prefixed variants such as GUIX_GTK3_PATH and GUIX_QT_PLUGIN_PATH which
> would be used by the Guix search paths specifications defined on these
> packages.

Yes, that will also works.

>
>> First patch add GUIX_LIBRARY_PATH to the default search paths, like PATH.
>> Second patch replace GDK_PIXBUF_MODULE_FILE with GUIX_LIBRARY_PATH.
>
> For the GDK_PIXBUF_MODULE_FILE special case, the problem is foremost
> that it's a single entry value; as mentioned previously it'd be nice if
> we could contribute a true multi-items variant named
> GDK_PIXBUF_MODULE_FILES that could point to more than one file.

Sure, but using GDK_PIXBUF_MODULE_FILES after upstreamed would also
cause problems for foreign system, since host programs will try to load
plugins from guix packages, which may or may not work, even crash.


> Alternatively we could use GUIX_GDK_PIXBUF_MODULE_FILE.

Another alternative is to make softwares "relocatable" to profile
directory, make them discovery plugins relative to their executables,
gdk-pixbuf does have a "relocatable" build option, but it use
"/proc/self/exe" which resolved to the final store path instead of
profile level directory.  Improve that likely could go upstreams, eg: by
first add 'g_get_executable_path' for glib:
https://gitlab.gnome.org/GNOME/glib/-/issues/31

It also open the chance to get rid of wrapper scripts (eg: by using a
virtualenv'd python as interpreter instead of wrap executables with
GUIX_PYTHONPATH), which I plan to play with later.  But this
"relocatable" way doesn't allow mix paths from differenet directories
(system and user profiles), it's good as it reduce the risk of
incompability, but not convenient.

So using specified GUIX_* variables are a must to avoid influence host
programs and use plugins from multiple profiles.


> But I don't see why we should use an intermetate GUIX_LIBRARY_PATH to
> compute all the other correct paths; this should be left to the search
> paths, in my opinion (as it's simpler, cleaner).

Well, lesser variables give a "clean" feeling, it's mostly aesthetic,
especially in GNOME and KDE, mixed with wrappers, there are a lot
variables "noise" in the environment.

Also think a litte more, as we need patching software anyway, I hope to
modify the logic `guix_build_library_path` to also include paths from
what wrappers currently provides, to drop wrappers.  That logic should
be simpler to implement in one place than for every specified variable.

Note that even with GUIX_ specified variables, they're still problems
since we have different profiles and problems built with different
versions of libraries.  Search "undefined symbol: __libc_pthread_init"
in the list could find some reports.

I think the final goal is:

- profile only provides PATH, GUIX_LIBRARY_PATH (replace most if not all
  other "libs/.*" paths), XDG_DATA_DIRS, INFOPATH, and other shareable
  (usually for data files, under the "share" directory) environment
  variables.

- no wrapper scripts for hardcoded plugins, so GUIX_LIBRARY_PATH only
  contains user, home, system profiles.

- if incompability problems occurs, we can just unset one
  GUIX_LIBRARY_PATH to launch the influenced program without
  incompatible plugins from profiles.  ofc this is temporary, you should
  not mix incompatible libraries (by update all packages in profile(s)
  at once), but handy for hurry adventurers.

If this looks reasonable, then I'd work on patch gtk or qt to get rid of
wrappers to justify this, how's this sound?


> Thanks for the initiative!  Let me know if I misunderstood something.

There is no misunderstood, thank you to let me think and clarify more.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.