qt-build-system: prefix or suffix env-variables in wrap-program

qt-build-system: prefix or suffix env-variables in wrap-program

[Hartmut Goebel]

Hi,

it came to my mind that currently the qt-build-system wraps the program
without passing along any environment variables. Thus e.g.
XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly
((guix build utils) wrap-program) supports prefixing or suffixing an
existing variable value.

Shall qt-build-system: prefix or suffix existing env-variables? Should
it become

    export
XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/gnu/store/…-kate-…"

or

    export
XDG_DATA_DIRS="/gnu/store/…-kate-…${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"

Currently affected variables are:

XDG_DATA_DIRS
XDG_CONFIG_DIRS
QT_PLUGIN_PATH
QML_IMPORT_PATH

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: qt-build-system: prefix or suffix env-variables in wrap-program

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Hi,
>
> it came to my mind that currently the qt-build-system wraps the program
> without passing along any environment variables. Thus e.g.
> XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly
> ((guix build utils) wrap-program) supports prefixing or suffixing an
> existing variable value.
>
> Shall qt-build-system: prefix or suffix existing env-variables? Should
> it become
>
>     export
> XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/gnu/store/…-kate-…"
>
> or
>
>     export
> XDG_DATA_DIRS="/gnu/store/…-kate-…${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"

Note that XDG Base Directory Specification [1] sets default values to
use for empty or unset XDG_* variables, for instance:

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

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-…"

or

  export XDG_DATA_DIRS="/gnu/store/…-kate-…:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"

[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

--
Mikhail

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: qt-build-system: prefix or suffix env-variables in wrap-program

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 781 bytes --]

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.

Anyway: Let me ask my question differently: Should the user be able to
*overrule* or only to *extend* guix's installation?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: qt-build-system: prefix or suffix env-variables in wrap-program

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

Sorry for the late reply.

Hartmut Goebel <h.goebel@crazy-compilers.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]