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: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 宋文武 <iyzsong <at> envs.net>
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 22:15:06 +0900

Hi,

宋文武 <iyzsong <at> envs.net> writes:

[...]

> 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.

Ah, I wasn't thinking about these being plugins depending on a specific
ABI, likely incompatible.  I see.

>> 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.

It sounds interesting, worth exploring.  But being unable to compose
multiple profile together easily defeats its purpose a bit (though the
same would be true with single valued variable such as
GDK_PIXBUF_MODULE_FILE: you can't honor the two profiles here, one has
to win).

> 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.

While aesthetic is nice, I'd rather to keep the design stupid simple and
rely on the search path mechanism; we can refine later.  Having 10 or 20
environment variables in my profile doesn't appear to be that big of a
deal to me.

> 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.

Sorry, I've lost you; what is this `guix_build_library_path` variable?
I'm not sure we'd be able to get rid of wrappers fully, as not
everything would be relative to lib.  I guess that's in the space to be
explored :-).

> 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.

Right.  It seems the responsibility of the user to avoid combining
incompatible software from different profiles.

> 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?

It's too early for me to say if it could really work, but I'll repeat
that a priori I'm not too fond of GUIX_LIBRARY_PATH (just the name would
clash with a GCC env var too) and custom logic that'd need to be
maintained in the software (we'd need to patch the software to have
GUIX_* variables anyway but the resulting patch would be trivial); I
think I'd rather have multiple, explicit environment variables computed
by search paths.

Just to make sure, GUIX_* variables would be honored *on top* of their
non GUIX_ prefixed (stock) variants, right?  E.g. we wouldn't want GCC
to stop honoring LIBRARY_PATH even if we add GUIX_LIBRARY_PATH, as that
would confuse users.

-- 
Thanks,
Maxim

Previous Next

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