(address . bug-guix@gnu.org)
20220223182046.553d9176@Jado
Hello! Over some time using Guix as an additional package manager in
different environments on Parabola and Trisquel, I have repeatedly run
into issues where something broke in the host system because of an
environment variable set by Guix.
#### Example 1
Usually this concerned $XDG_DATA_DIRS. The problem with this variable
stems from the XDG Base Directory Specification [1], which says that:
Toggle quote (3 lines)
> If $XDG_DATA_DIRS is either not set or empty, a value equal to
> /usr/local/share/:/usr/share/ should be used.
From what I’ve heard from others, some environments automatically set
this variable; others, however, do not set the variable, instead having
the system fall back to the value shown above. I have observed the
latter behaviour in GNOME 3 and Window Maker.
Guix currently prepends its own paths to the existing value, which
works fine when there *is* an existing value. When there is no value
and the system is relying on the fall-back, Guix sets the value to its
own paths only. This means the local, non-guix applications will no
longer look for the data in ‘/usr/local/share/’ or ‘/usr/share/’, where
they are stored, and will break, possibly condemning the user to resort
to the command line.
#### Example 2
Just now I tried to clone a git repository. Git is installed on the
host system and is not found in my Guix profile. Yet the cloning has
failed with the following message:
Toggle quote (6 lines)
> fatal: unable to access
> 'https://framagit.org/peppercarrot/webcomics.git/': server
> certificate verification failed. CAfile:
> /home/tirifto/.guix-profile/etc/ssl/certs/ca-certificates.crt
> CRLfile: none
All I had to do was to unset $GIT_SSL_CAINFO, apparently set by Guix,
and everything worked again.
#### Comment
I suppose problems like this cannot always be prevented automagically.
But whenever that happens to be the case, perhaps the possibility of
them happening could be exposed to the user in a more prominent way?
I can deal with the two issues mentioned above with ease, since:
1. I know environment variables exist and parts of the system rely on
them for stuff.
2. I know that Guix sets its own environment variables and modifies
existing ones.
3. When something breaks, it either points me to a Guix-related path,
or I remember by myself to check if Guix has changed something
relevant.
But the first time I had a problem with $XDG_DATA_DIRS, it took me a
while to find the cause.
I imagine that right now, running Guix is very much a conscious
decision made by users who are at least somewhat comfortable with the
command line and the internal workings of their system, so this does
not present an insurmountable problem for them. But it might for other
types of users (who might become more common in the future, I suppose).
As one hypothetical solution, would it be possible for Guix to include
default values in its paths if it’s running on a host system and there
are no values set, but it is known that fallback values may be used? I
have no idea how practical this would be on the Guix side of things.
Alternatively, perhaps the more ubiquitous variables could be given a
mention or their own section in the manual, so that the user will know
to set values for them when setting Guix up? Perhaps something similar
could be done for individual packages which set some variables, with
the user being informed about their use on installation, should they
wish to set their values or note them for reference in case of issues
in the future?
Perhaps this is less of a technical bug and more of a design issue, but
this seemed like the best place to bring it up nevertheless. Sorry if
that is not the case!
Best of wishes
// Tirifto
[1]