[bug#76428] [GCD PATCH] 003-set-search-paths-without-program-wrappers: Submit.

[Ludovic Courtès]

Hi 宋文武,

First of all, apologies for not really contributing to the discussion
before.

My sentiment could be summarized as: I agree with the rationale, I like
the idea of storing search path metadata in package outputs, but I’m
concerned about the maintainability and viability of some aspects of the
proposal (see below).  I’ll send my deliberation in a separate message.

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

>   ld.so.cache
>   search-paths.d
>     GUIX_XDG_DATA_DIRS
>     GUIX_GIO_EXTRA_MODULES
>     GUIX_GTK4_PATH

I don’t think the “GUIX_” prefix is really justified in the proposal.

There’s a precedent, ‘GUIX_PYTHONPATH’, but I think it does not follow
that this can be generalized to every search path environment variable.

For example, the XDG_ variables are honored by a lot of software, not
just GLib- or Qt-based software, and it’s unrealistic to patch them all.
It’s also undesirable: generally speaking, we want to stay as close to
upstream as possible so that documentation, tutorials, and scripts found
elsewhere also work on Guix.

> ## Find the location of the current executable
>
> To find its search path configuration files when an executable is running,
> we can first find the location of the executable.  Conveniently, Linux
> provides a pseudo-file `/proc/self/exe` for this exact purpose, which works
> well for ELF executables.   But for an interpreter script, `/proc/self/exe`
> would return the file name of its interpreter instead of the script, so
> we patch interpreters to set 2 environment variables:
>
>   - `GUIX_INTERPRETER_FILE`: absolute file name of the interpreter
>   - `GUIX_MAIN_SCRIPT_FILE`: absolute file name of the script

We won’t patch every interpreter out there, that’s not reasonable.

These two variables could also have unexpected consequences since an
attacker could override them to cause confusion.

> ## Implementation plan
>
> A WIP implementation can be found in <https://issues.guix.gnu.org/75688>.
>
> - Add a new function `g_guix_build_search_path_dirs` to GLib, which returns a
>   search path as a list of file or directory names from a search path
>   configuration file and an environment variable.
> - Patch GLib to use `g_guix_build_search_path_dirs` for `GUIX_XDG_DATA_DIRS`,
>   `GUIX_XDG_CONFIG_DIRS`, `GUIX_GIO_EXTRA_MODULES` and
>   `GUIX_GSETTINGS_SCHEMA_DIR`.
> - Patch Python to set `GUIX_INTERPRETER_FILE` and `GUIX_MAIN_SCRIPT_FILE`.
> - Patch Qt to use `g_guix_build_search_path_dirs` for `GUIX_XDG_DATA_DIRS`,
>   `GUIX_XDG_CONFIG_DIRS`, `GUIX_QT_PLUGIN_PATH`, `GUIX_QML_IMPORT_PATH`,
>   `GUIX_QML2_IMPORT_PATH`.
> - Modify `glib-or-gtk-build-system` to get rid of `wrap-program`.
> - Modify `qt-build-system` to get rid of `wrap-program`.

I’m concerned about the cost of maintaining these patches.  Again, the
ld.so patch (for glibc) sets a precedent, but this part of glibc changes
relatively rarely, and it’s just one patch; what if we have to maintain
ten such patches in big and changing libraries like GLib and Qt?

Overall, I think I’d be reassured if we reduced the scope a little bit:
don’t insist on the “GUIX_” prefix, focus on GTK and Qt applications.

Thanks,
Ludo’.