Subject: Re: [bug#75688] [PATCH 0/2] Introduce GUIX_LIBRARY_PATH to replace harmful environment variables

From: Maxim Cournoyer <[email-masked]>
Date: Tue, 21 Jan 2025 22:19:49 +0900

Hello,

宋文武 <[email-masked]> writes:

[...]

> Okay, I changed the plan, since use only one env like GUIX_LIBRARY_PATH
> would lead to some form of 'stats storm', and the logic is not harder
> for patching different variables. If we get rid of wrapper scripts, the
> "noise" will only contains profile paths, so are acceptable..
>
> Now I get this patch for glib:
>
> 1. add a `gchar **g_build_guix_search_path_dirs (const gchar *variable)`
>    function to GLIB, which handle .VARIABLE file in addition to the env
>    value.  Those .VARIABLE files sit at the same directory of
>    executable, would be used to replace wrapper script.  As said early,
>    wrapper scripts leaks environment variables could cause incompatable
>    problems.
>
> 2. Use `g_build_guix_search_path_dirs` for GUIX_GIO_EXTRA_MODULES,
>    GUIX_GSETTINGS_SCHEMA_DIR, and etc. (later).
>    
> 3. (later) Modify wrap-program usages to use .VARIABLE files to get rid
>    of environment variables leaks.

This reminds me of how Python virtualenv works, IIRC.  What do you mean
by "wrapper scripts leak environment variables and could cause
incompatibility problems" ?  Sure, if your term binary is wrapped, your
shell will have these environment variables as its a child process
inheriting its parent environment, but otherwise I'm not sure I
understand the issue, especially how processing a .VARIABLE file instead
would handle this better?  Could yo give an example?

-- 
Thanks,
Maxim