Guix should not set global variables that may affect host

  • Open
  • quality assurance status badge
Details
3 participants
  • ???
  • Liliana Marie Prikler
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
Merged with
M
M
Maxim Cournoyer wrote on 24 Jan 2022 23:24
(name . bug-guix)(address . bug-guix@gnu.org)
87zgnk4vs2.fsf@gmail.com
Hello!

There are multiple reports about the negative effects of Guix setting
variables such as XDG_DATA_DIRS on foreign distributions, that may cause
problems a severe as locking users out of their graphical session [0].

In my opinion, we should pursue patching every application/library to
use a Guix-specific variant, e.g. GUIX_XDG_DATA_DIRS instead of
XDG_DATA_DIRS, to avoid interfering with the host system, as was done
for GUIX_PYTHONPATH.

This is a big task in itself; we can open more focused/actionable tasks
for each environment variable, starting with those causing the most
serious issues.

Any takers?

Maxim

L
L
Liliana Marie Prikler wrote on 25 Jan 2022 08:21
e7aac16cd2f922576d3c8da29bece57aa6b3c353.camel@ist.tugraz.at
Hi,

Am Montag, dem 24.01.2022 um 17:24 -0500 schrieb Maxim Cournoyer:
Toggle quote (17 lines)
> Hello!
>
> There are multiple reports about the negative effects of Guix setting
> variables such as XDG_DATA_DIRS on foreign distributions, that may
> cause problems a severe as locking users out of their graphical
> session [0].
>
> In my opinion, we should pursue patching every application/library to
> use a Guix-specific variant, e.g. GUIX_XDG_DATA_DIRS instead of
> XDG_DATA_DIRS, to avoid interfering with the host system, as was done
> for GUIX_PYTHONPATH.
>
> This is a big task in itself; we can open more focused/actionable
> tasks for each environment variable, starting with those causing the
> most serious issues.
>
> Any takers?
I'm not convinced that patching XDG_DATA_DIRS is a good solution here.
Even if we go forward and implement this for each and every
library/application, (it would be reasonably simple to do so for glib
and qt at least, but there's many more consumers, including Guix
itself), we'd just force users on foreign distros to set up their
XDG_DATA_DIRS for us if they e.g. want to have desktop icons available,
so they'd quickly encounter the same issue on their own.

I see two ways forward for this: First, "ignore it" and just document
the behaviour. This isn't just a bug Guix is suffering from, it also
affects other third-party package installers like Flatpak and Snap.
Since distros increasingly become aware of them, this will soon no
longer be an issue for most our users. Second, extend search-paths
with a way of enforcing a default value when none is set. This way,
Guix will still override XDG_DATA_DIRS, but since
$HOME/.local/share:/usr/share is set as the default as per spec, it
will do what the distro expected.

WDYT?
M
M
Maxim Cournoyer wrote on 26 Jan 2022 00:14
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 53514@debbugs.gnu.org)
87a6fj4ddg.fsf@gmail.com
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

Toggle quote (28 lines)
> Hi,
>
> Am Montag, dem 24.01.2022 um 17:24 -0500 schrieb Maxim Cournoyer:
>> Hello!
>>
>> There are multiple reports about the negative effects of Guix setting
>> variables such as XDG_DATA_DIRS on foreign distributions, that may
>> cause problems a severe as locking users out of their graphical
>> session [0].
>>
>> In my opinion, we should pursue patching every application/library to
>> use a Guix-specific variant, e.g. GUIX_XDG_DATA_DIRS instead of
>> XDG_DATA_DIRS, to avoid interfering with the host system, as was done
>> for GUIX_PYTHONPATH.
>>
>> This is a big task in itself; we can open more focused/actionable
>> tasks for each environment variable, starting with those causing the
>> most serious issues.
>>
>> Any takers?
> I'm not convinced that patching XDG_DATA_DIRS is a good solution here.
> Even if we go forward and implement this for each and every
> library/application, (it would be reasonably simple to do so for glib
> and qt at least, but there's many more consumers, including Guix
> itself), we'd just force users on foreign distros to set up their
> XDG_DATA_DIRS for us if they e.g. want to have desktop icons available,
> so they'd quickly encounter the same issue on their own.

They may end up doing so, but at least they wouldn't be locked out of
their graphical session just for installing a package from Guix, which
is a clear improvement over the current situation.

Toggle quote (11 lines)
> I see two ways forward for this: First, "ignore it" and just document
> the behaviour. This isn't just a bug Guix is suffering from, it also
> affects other third-party package installers like Flatpak and Snap.
>
> Since distros increasingly become aware of them, this will soon no
> longer be an issue for most our users. Second, extend search-paths
> with a way of enforcing a default value when none is set. This way,
> Guix will still override XDG_DATA_DIRS, but since
> $HOME/.local/share:/usr/share is set as the default as per spec, it
> will do what the distro expected.

That sounds good to, and should be easier to achieve.

Thanks,

Maxim
?
control message for bug #54129
(address . control@debbugs.gnu.org)
d8a76d5e7a751084@localhost
merge 54129 53514
quit
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 53514@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 53514
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch