[bug#45064] [PATCH 0/2] Set environment variables for GTK+ input methods via profile startup files

[宋文武 <iyzsong@outlook.com>]

Leo Prikler <leo.prikler@student.tugraz.at> writes:

> Hello, 宋文武!
>
> As the author of [1] I might be a bit biased, but I have a few
> questions regarding this patch set:
Hello, thanks for asking!

> 1. Will it correctly pick up IM_MODULE_FILEs at system level if you
> also happen to have GTK+ applications installed at user level?
Oh, if I have ibus in system profile, and no input methods but GTK+
applications in user profile, then it will be broken, as user's profile
was source later in '/etc/profile', replace the IM_MODULE_FILE from
system profile.  Need more think...

>   a. What about multi-profile setups, where more than one profile
> contains GTK+ applications?
Because only a single variable for all gtk+ versions, We can only hope
those GTK+ applications from different profiles can accept the same
input methods modules, this patch dosen't improve the situation.

>   b. What about `guix environment`?
For `guix environment`, it dosen't load `/etc/profile`, so this have no
effect, but maybe we should make it doing so?

> 2. Which purpose would sourcing those files offer other than setting
> environment variables?  What would be permissible actions?  Remember,
> that those would be executed whenever the user spawns a shell, so while
> you could put stuff like `fc-cache -r` in there, I personally think you
> ought not to.
Sure, for set environment variables, I can't came up with other
examples. It's just like support '/etc/profile.d', but there are some
packages (for now, only nix I think) that will set environment variables
outside of store and profile (NIX_PATH=$HOME/.nix-defexpr/channels, etc)
which would be difficult for search-paths.  I agree with you that
profile should not run things that modify files.


>
> I believe a proper fix for GTK would be to allow setting multiple
> IM_MODULE_FILEs instead of a single one and using search paths.
Our search paths can be a single file (eg: SSL_CERT_FILE) or mutiple
files, but we need to add it to all GTK+ input methods (only ibus and
fcitx, but it's like GST_PLUGIN_SYSTEM_PATH every where, not ideal), my
point is that set thoses environment varaibles once profile level is
better than set them many times each package.  If profile hook can
contribute to the search-paths of manifest, I'd go for it.

So in the end, this may only bring benifits for packages that came up
with profile scripts in etc/profile.d, and I need to think more for
multiple profiles...

Thank you!