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

[Alex Kost <alezost@gmail.com>]

Ludovic Courtès (2015-11-21 23:10 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-11-21 11:57 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:
>>>>
>>>>> -# Load the system profile's settings.
>>>>> +if [ -x /run/current-system/profile/bin/guix ]
>>>>> +then
>>>>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the
>>>>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when
>>>>> +  # computing the search paths.
>>>>> +  #
>>>>> +  # This may take a few hundred milliseconds, but it's OK because this is
>>>>> +  # performed for log-in shells only.
>>>>> +  eval `/run/current-system/profile/bin/guix package \\
>>>>> +          -p /run/current-system/profile             \\
>>>>> +          -p \"$HOME/.guix-profile\" --search-paths`
>>>>
>>>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against
>>>> running 'guix' (or any other program) in /etc/profile.
>>>
>>> Why?  (Honest question.)
>>
>> At first, because of the slowdown: it may be a few hundred milliseconds
>> for you, but it's several seconds for me.
>
> Really?  Can you show the output of:
>
>   time guix package -p /run/current-system/profile \
>                     -p ~/.guix-profile --search-paths

real	0m2.634s
user	0m0.568s
sys	0m0.080s

Of course, on the second run the real time reduces (for me it's about
0.5), as HDD already "knows" what I want, but since it is for login
shell, it will always be 2-3 seconds because of HDD.

>> But actually, even if it was several milliseconds, I still wouldn't
>> like it, as (IMHO) /etc/profile should only set variables, and not run
>> external programs.
>
> I don’t buy this “principle”: /etc/profile is a program, and the output
> of --search-paths is trusted to contain only environment variable
> setting.

Sure, it's just my opinion (OK, let call it "faith"): I consider running
external programs in "/etc/profile" malicious.

> In the discussion of this bug, we tried hard to avoid resorting to
> invoking a program, but ultimately no other solution came out.

I don't need a solution for this bug, I just want to have an option to
avoid invoking "guix package --search-paths" in my "/etc/profile".

>>>> I would really like to have an option to avoid this.  Is it possible?
>>>
>>> Not that I know of.  Please read <http://bugs.gnu.org/20255>.
>>
>> What about making some environment variable which will be honored by
>> 'operating-system-etc-service' procedure.  So depending on this variable
>> that 'eval ...' command will or will not be added to "/etc/profile"
>> during 'guix system ...' process.
>>
>> For example, when I do:
>>
>>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm
>>
>> the "etc/profile" of the built system will not contain those 'eval ...'
>> lines.  WDYT?
>
> This would be unreasonable.  We’re talking about a basic feature here.
> If basic features are broken to the point that we prefer to offer ways
> to bypass them, and have a semi-broken system, then there’s a problem,
> IMO.

Sorry, but I would really like to bypass this feature, as I don't like
it.  For me, what you suggest sounds: «We'll not give a freedom to a
user to disable this feature, because we know better what is good for
him/her».  All I ask is to give me such a freedom.

Using --search-paths with several profiles is a great feature (thank you
for it!) and I like it, but consider the following use-case: for some
reason I like to manage several profiles instead of a single
"~/.guix-profile", so I can put:

eval `guix package -p /run/current-system/profile \
                   -p ~/.guix-profile \
                   -p ~/my-guix-profiles/foo \
                   -p ~/my-guix-profiles/bar \
                   --search-paths`

in my "~/.bash_profile".  So I don't like to have the same command but
only for 2 profiles in my "/etc/profile".  Please, give me an option to
disable this feature.

-- 
Alex