Sorry for the late reply. Hartmut Goebel writes: > Am 11.12.19 um 21:25 schrieb Mikhail Kryshen: >> So the correct way to extend XDG_DATA_DIRS would be >> >> export XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…" > > I'm quite confident, adding /usr/share etc. here as default would be > wrong from a guix point of view: This would break isolation of > environments. On a foreign distribution this would even give the foreign > distribution's installation precedence over guix's. The problem is that conforming programs treat empty or unset XDG_DATA_DIRS as "/usr/local/share/:/usr/share/", for such programs XDG_DATA_DIRS="" and XDG_DATA_DIRS="/usr/local/share/:/usr/share/" are equivalent, and thus their extensions should be equivalent too. Empty or unset XDG_DATA_DIRS already breaks isolation: when it is empty, it means (according to the spec) that programs are supposed to refer to /usr in the current environment. Because of this, I think that in pure Guix environment XDG_*_DIRS variables should never be left unset (and so /usr will not be referred to implicitly and will not appear in the extended value). Overriding the value (including the implicit "/usr/local/share/:/usr/share/") will cause problems when wrapped program launches a non-guix program from the host system (e.g. MUA opening an attachment) that will inherit its environment. > Anyway: Let me ask my question differently: Should the user be able to > *overrule* or only to *extend* guix's installation? Allowing to overrule will be problematic, because XDG_*_DIRS may be set by the system and include directories with conflicting files (e.g. from different version of the same program installed in the system profile or in the host non-guix system). So I suggest prefixing XDG_*_DIRS like this: XDG_DATA_DIRS="/gnu/store/…:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}" So the added path gets higher priority, and the other paths are preserved, including the implicit "/usr/local/share/:/usr/share/" in case of initially empty variable. -- Mikhail