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

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

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.