GNU bug report logs - #54129
Guix’s environment variables can break the host system

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: Tirifto <tirifto@HIDDEN>; merged with #53514; dated Wed, 23 Feb 2022 17:21:01 UTC; Maintainer for guix is bug-guix@HIDDEN.
Merged 53514 54129. Request was from 宋文武 <iyzsong@HIDDEN> to control <at> Full text available.

Message received at submit <at>

Received: (at submit) by; 23 Feb 2022 17:20:58 +0000
From debbugs-submit-bounces <at> Wed Feb 23 12:20:58 2022
Received: from localhost ([]:46391
	by with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at>>)
	id 1nMvJx-0004Ya-LB
	for submit <at>; Wed, 23 Feb 2022 12:20:58 -0500
Received: from ([]:34430)
 by with esmtp (Exim 4.84_2)
 (envelope-from <tirifto@HIDDEN>) id 1nMvJv-0004YN-B0
 for submit <at>; Wed, 23 Feb 2022 12:20:55 -0500
Received: from ([]:50426)
 by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <tirifto@HIDDEN>) id 1nMvJv-0002wr-58
 for bug-guix@HIDDEN; Wed, 23 Feb 2022 12:20:55 -0500
Received: from ([]:49731)
 by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <tirifto@HIDDEN>) id 1nMvJr-0003Bp-Vx
 for bug-guix@HIDDEN; Wed, 23 Feb 2022 12:20:54 -0500
Received: from submission ( []) 
 by (Postfix) with ESMTPS id 4A359240103
 for <bug-guix@HIDDEN>; Wed, 23 Feb 2022 18:20:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=2017;
 t=1645636848; bh=vi6XzKccYIkKSWtDsaQ3M89c2WSyZ3lX52yrjTbBkB0=;
Received: from customer (localhost [])
 by submission ( with ESMTPSA id 4K3jVR3XBhz9rxD
 for <bug-guix@HIDDEN>; Wed, 23 Feb 2022 18:20:47 +0100 (CET)
Date: Wed, 23 Feb 2022 17:20:46 +0000
From: Tirifto <tirifto@HIDDEN>
To: bug-guix@HIDDEN
Subject: =?UTF-8?B?R3VpeOKAmXM=?= environment variables can break the host
Message-ID: <20220223182046.553d9176@Jado>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=; envelope-from=tirifto@HIDDEN;
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at>
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <>
List-Unsubscribe: <>, 
 <mailto:debbugs-submit-request <at>>
List-Archive: <>
List-Post: <mailto:debbugs-submit <at>>
List-Help: <mailto:debbugs-submit-request <at>>
List-Subscribe: <>, 
 <mailto:debbugs-submit-request <at>>
Errors-To: debbugs-submit-bounces <at>
Sender: "Debbugs-submit" <debbugs-submit-bounces <at>>
X-Spam-Score: -2.3 (--)

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:

> If $XDG_DATA_DIRS is either not set or empty, a value equal to
> /usr/local/share/:/usr/share/ should be used.

=46rom what I=E2=80=99ve heard from others, some environments automatically s=
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=C2=A03 and Window=C2=A0Maker.

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 =E2=80=98/usr/local/share/=E2=80=99 or =E2=80=
=98/usr/share/=E2=80=99, 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:

> fatal: unable to access
> '': 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

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=E2=80=99s running on a host system and th=
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


Acknowledgement sent to Tirifto <tirifto@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#54129; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 6 Feb 2023 07:45:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.