bug#20255: 'search-paths' should respect both user and system profile.

[Maxim Cournoyer]

Hello,

Alex Kost <alezost@gmail.com> writes:

> zimoun (2020-02-21 16:53 +0100) wrote:
>
>> Dear,
>>
>> What is the status of the bug#20255 [1]?
>> It is old; the last activity seems back on 2015, November. So let resume.
>>
>> The issue is, e.g.:
>>  - perl installed into the system profile
>>  - perl-xml-parser installed into an user profile
>> Then "guix package --search-paths" does not set correctly XML::Parser.
>>
>>
>> Fixes had been pushed: dedb17a and b2a7223 and cc3de1d.
>>
>> The final fix is still missing. Because it is a controversial patch
>> [2] :-) i.e., running 'guix' in '/etc/profile'; see these lines of the
>> patch:
>>
>> +  eval `/run/current-system/profile/bin/guix package \\
>> +          -p /run/current-system/profile             \\
>> +          -p \"$HOME/.guix-profile\" --search-paths`
>>
>>
>> The friendly "protest" [3] is about turning these lines optional via
>> an environment variable. I am not sure to follow where the discussion
>> had been going then.
>
> As for me, I am OK with any default setting as long as there is a way to
> change it.  I recall Ludovic proposed a patch that allowed to customize
> "/etc/profile" and I was happy about it, but he changed his mind on that
> patch so it was never committed.

Do you still have a vetted interest in the issue at hand?  This is a
serious usability problem that's been in limbo for 6 years, apparently
for reasons of purity (not wanting to run a command in /etc/profile).
While I share the sentiment that /etc/profile would better be 'inert' or
static, it seems we haven't been able to come up with a better solution
than calling 'guix package --search-paths'.  Like Ludovic, I also don't
find the idea of allowing users to override /etc/profile very appealing;
even if undocumented, its mere presence in the operating-system field
would be an invitation for problems.  An environment variable to disable
such basic functionality also seems backward to me.

I would personally be in favor of committing the fix as-is.  If < 1 s of
wasted time on boot is an issue, I suggest to look into GNU Shepherd to
offset it; optimization opportunities should abound :-).

Thank you,

Maxim