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

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

[宋文武]

Currently, search-paths built only from packages in user's profile.
As reported by Andy Wingo in #guix, when I have:
  perl installed into system profile
  perl-xml-parser installed into user profile
  
guix package --search-paths won't give a hint about PERL5LIB,
so it's very likely end up with a broken XML::Parser.
Another interesting fact is that we have both guile and guix in
system profile, but the guix modules isn't work out-of-the-box
on GuixSD.

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

[Ludovic Courtès]

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

宋文武 <iyzsong@gmail.com> skribis:

> Currently, search-paths built only from packages in user's profile.
> As reported by Andy Wingo in #guix, when I have:
>   perl installed into system profile
>   perl-xml-parser installed into user profile
>   
> guix package --search-paths won't give a hint about PERL5LIB,
> so it's very likely end up with a broken XML::Parser.

Rather it ends up with no XML::Parser, no?

That said, I’m not sure how this could be improved.  We could hard-code
lookup in /run/current-system/profile/.  OTOH that’s not different from
installing perl in one profile, and perl-xml-parser in another
(arbitrary) profile, which ‘guix package’ cannot be aware of.

WDYT?

> Another interesting fact is that we have both guile and guix in
> system profile, but the guix modules isn't work out-of-the-box
> on GuixSD.

(But guix.el *does* work out of the box.)

For a start, what about augmenting /etc/profile:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 830 bytes --]

diff --git a/gnu/system.scm b/gnu/system.scm
index 0d510b6..bcc4919 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -447,6 +447,8 @@ export PATH=$HOME/.guix-profile/bin:/run/current-system/profile/bin
 export PATH=/run/setuid-programs:/run/current-system/profile/sbin:$PATH
 export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
 export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
+export GUILE_LOAD_PATH=$HOME/share/guile/site/2.0:/run/current-system/profile/share/guile/site/2.0
+export GUILE_LOAD_COMPILED_PATH=$HOME/share/guile/site/2.0:/run/current-system/profile/share/guile/site/2.0
 
 export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
 export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


Thanks,
Ludo’.

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

[宋文武]

Ludovic Courtès <ludo@gnu.org> writes:

> 宋文武 <iyzsong@gmail.com> skribis:
>
>> Currently, search-paths built only from packages in user's profile.
>> As reported by Andy Wingo in #guix, when I have:
>>   perl installed into system profile
>>   perl-xml-parser installed into user profile
>>   
>> guix package --search-paths won't give a hint about PERL5LIB,
>> so it's very likely end up with a broken XML::Parser.
>
> Rather it ends up with no XML::Parser, no?
>
> That said, I’m not sure how this could be improved.  We could hard-code
> lookup in /run/current-system/profile/.  OTOH that’s not different from
> installing perl in one profile, and perl-xml-parser in another
> (arbitrary) profile, which ‘guix package’ cannot be aware of.
>
> WDYT?
As 'guix package' is for only one profile, that's fine.
Since we can get search-paths from system profile using:
  guix package -p /run/current-system/profile --search-paths

I think the missing is to check whether we are under GuixSD,
and then merge those 2 search-paths object in scheme level
to get a full search-paths.

Or better to generate a 'profile' script for each manifest, and then
merged in shell level, so it can work out-of-the-box. How about:
  - /etc/profile:
    # configuration for the whole system goes here.
    # shouldn't refer profile paths.
    export LANG=en_US.utf8
    export SSL_CERT_DIR=/etc/ssl/certs
    export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
    [...]

    source /run/current-system/profile/etc/profile

    if [ -f $HOME/.guix-profile/etc/profile ]; then
      source $HOME/.guix-profile/etc/profile
    fi

    # honor setuid-programs
    export PATH=/run/setuid-programs:$PATH

  - /run/current-system/profile/etc/profile:
    export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH
    export MANPATH=/run/current-system/profile/share/man:$PATH
    [...]
    
  - ~/.guix-profile/etc/profile:
    export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH
    [...]

The idea to generate profile from search-paths is not new,
I heard it from you IIRC.
I think it's the time to do it.

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

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

> As 'guix package' is for only one profile, that's fine.
> Since we can get search-paths from system profile using:
>   guix package -p /run/current-system/profile --search-paths

Right.

> I think the missing is to check whether we are under GuixSD,
> and then merge those 2 search-paths object in scheme level
> to get a full search-paths.
>
> Or better to generate a 'profile' script for each manifest, and then
> merged in shell level, so it can work out-of-the-box. How about:
>   - /etc/profile:
>     # configuration for the whole system goes here.
>     # shouldn't refer profile paths.
>     export LANG=en_US.utf8
>     export SSL_CERT_DIR=/etc/ssl/certs
>     export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>     [...]
>
>     source /run/current-system/profile/etc/profile
>
>     if [ -f $HOME/.guix-profile/etc/profile ]; then
>       source $HOME/.guix-profile/etc/profile
>     fi
>
>     # honor setuid-programs
>     export PATH=/run/setuid-programs:$PATH
>
>   - /run/current-system/profile/etc/profile:
>     export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH
>     export MANPATH=/run/current-system/profile/share/man:$PATH
>     [...]
>     
>   - ~/.guix-profile/etc/profile:
>     export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH
>     [...]
>
> The idea to generate profile from search-paths is not new,
> I heard it from you IIRC.
> I think it's the time to do it.

Agreed, the plan makes sense and I think we have all the bits.

A related question is whether to encode search path environment
variables into the manifest (currently they are “guessed” by looking at
same-named packages; see (guix build package).)  I think that would
probably simplify things and make it easier to share this environment
variable code.

Thoughts?

Thanks,
Ludo’.

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

[宋文武]

> [...]
>>
>> The idea to generate profile from search-paths is not new,
>> I heard it from you IIRC.
>> I think it's the time to do it.
>
> Agreed, the plan makes sense and I think we have all the bits.
>
> A related question is whether to encode search path environment
> variables into the manifest (currently they are “guessed” by looking at
> same-named packages; see (guix build package).)  I think that would
> probably simplify things and make it easier to share this environment
> variable code.
>
> Thoughts?
I see, currently search-paths depends on the packages recipes. If we
update the related scheme code, then search-paths got updated, even we
didn't touch packages in profile at all.  It's a little confusing.
So I think we should encode the search-paths for each package in
manifest.
> Thanks,
> Ludo’.

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

[Mark H Weaver]

宋文武 <iyzsong@gmail.com> writes:

>> [...]
>>>
>>> The idea to generate profile from search-paths is not new,
>>> I heard it from you IIRC.
>>> I think it's the time to do it.
>>
>> Agreed, the plan makes sense and I think we have all the bits.
>>
>> A related question is whether to encode search path environment
>> variables into the manifest (currently they are “guessed” by looking at
>> same-named packages; see (guix build package).)  I think that would
>> probably simplify things and make it easier to share this environment
>> variable code.
>>
>> Thoughts?
> I see, currently search-paths depends on the packages recipes. If we
> update the related scheme code, then search-paths got updated, even we
> didn't touch packages in profile at all.  It's a little confusing.
> So I think we should encode the search-paths for each package in
> manifest.

I agree.

     Mark

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

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

>> [...]
>>>
>>> The idea to generate profile from search-paths is not new,
>>> I heard it from you IIRC.
>>> I think it's the time to do it.
>>
>> Agreed, the plan makes sense and I think we have all the bits.
>>
>> A related question is whether to encode search path environment
>> variables into the manifest (currently they are “guessed” by looking at
>> same-named packages; see (guix build package).)  I think that would
>> probably simplify things and make it easier to share this environment
>> variable code.
>>
>> Thoughts?
> I see, currently search-paths depends on the packages recipes. If we
> update the related scheme code, then search-paths got updated, even we
> didn't touch packages in profile at all.  It's a little confusing.
> So I think we should encode the search-paths for each package in
> manifest.

Done in dedb17a.

That will make it easier to generate environment variable settings.

Ludo’.

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

[Ludovic Courtès]

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

ludo@gnu.org (Ludovic Courtès) skribis:

> 宋文武 <iyzsong@gmail.com> skribis:
>
>>> [...]
>>>>
>>>> The idea to generate profile from search-paths is not new,
>>>> I heard it from you IIRC.
>>>> I think it's the time to do it.
>>>
>>> Agreed, the plan makes sense and I think we have all the bits.
>>>
>>> A related question is whether to encode search path environment
>>> variables into the manifest (currently they are “guessed” by looking at
>>> same-named packages; see (guix build package).)  I think that would
>>> probably simplify things and make it easier to share this environment
>>> variable code.
>>>
>>> Thoughts?
>> I see, currently search-paths depends on the packages recipes. If we
>> update the related scheme code, then search-paths got updated, even we
>> didn't touch packages in profile at all.  It's a little confusing.
>> So I think we should encode the search-paths for each package in
>> manifest.
>
> Done in dedb17a.
>
> That will make it easier to generate environment variable settings.

Here’s the patch that does that, to try on b2a7223 or later.

Could you comment and give it a try?  My main concern was the latency
introduced at log-in shells, but it’s OK, at least on my i5+SSD laptop.

--8<---------------cut here---------------start------------->8---
$ time guix package -p ~/.guix-profile -p /run/current-system/profile --search-paths > /dev/null

real    0m0.290s
user    0m0.372s
sys     0m0.028s
$ guix package -I | wc -l
215
$ guix package -p /run/current-system/profile -I | wc -l
43
--8<---------------cut here---------------end--------------->8---

I’ll push it soon if there are no objections.

TIA!

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2383 bytes --]

diff --git a/gnu/system.scm b/gnu/system.scm
index 2755d85..7d1d33e 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -429,35 +429,49 @@ export SSL_CERT_DIR=/etc/ssl/certs
 export SSL_CERT_FILE=\"$SSL_CERT_DIR/ca-certificates.crt\"
 export GIT_SSL_CAINFO=\"$SSL_CERT_FILE\"
 
-# Crucial variables that could be missing in the profiles' 'etc/profile'
-# because they would require combining both profiles.
-# FIXME: See <http://bugs.gnu.org/20255>.
-export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
-export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
+# Search paths for GLib schemas, GTK+ icons, and so on.
 export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
 export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
 
 # Ignore the default value of 'PATH'.
 unset PATH
 
-# 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`
+else
+  # In the unlikely case that Guix is not in the global profile,
+  # fall back to the simpler, yet less accurate method (see
+  # <http://bugs.gnu.org/20255>.)
   GUIX_PROFILE=/run/current-system/profile \\
   . /run/current-system/profile/etc/profile
 
-# Prepend setuid programs.
-export PATH=/run/setuid-programs:$PATH
-
   if [ -f \"$HOME/.guix-profile/etc/profile\" ]
   then
     # Load the user profile's settings.
     GUIX_PROFILE=\"$HOME/.guix-profile\" \\
     . \"$HOME/.guix-profile/etc/profile\"
-else
+  fi
+fi
+
+if [ ! -f \"$HOME/.guix-profile\" ]
+then
   # At least define this one so that basic things just work
   # when the user installs their first package.
   export PATH=\"$HOME/.guix-profile/bin:$PATH\"
 fi
 
+# Prepend setuid programs.
+export PATH=/run/setuid-programs:$PATH
+
 # Append the directory of 'site-start.el' to the search path.
 export EMACSLOADPATH=:/etc/emacs
 

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

[Alex Kost]

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.  I would really
like to have an option to avoid this.  Is it possible?

-- 
Thanks,
Alex

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

[Ludovic Courtès]

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.)

> 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>.

Ludo’.

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

[Alex Kost]

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.  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 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?

-- 
Alex

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

[Ludovic Courtès]

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

?

> 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.

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

>>> 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.

Ludo’.

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

[Alex Kost]

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

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

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

Ouch, that’s a problem.  This suggests that this is 2 seconds of I/O.
I’m not sure what can be done to improve that.

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

Are you denying that this is a bug?  Are you denying that there’s a
usability issue at hand?

To me, what 宋文武 reported at the beginning of this thread is a
usability issue.  We’ve hacked around it so far, but we know there are
cases where the hacks aren’t enough.

We could declare it as “won’t fix”, but I’m not comfortable with that.

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

[...]

I very well understand your concern, so thanks for chiming in.
Please let’s also consider the bug at hand.

The solution I came up with might be inadequate.  Then we need to come
up with an alternate proposal, or to resign and mark it as “wontfix.”

What would you suggest?

Thanks,
Ludo’.

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

[Alex Kost]

Ludovic Courtès (2015-11-22 13:52 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>>>> 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
>
> Ouch, that’s a problem.  This suggests that this is 2 seconds of I/O.
> I’m not sure what can be done to improve that.
>
>>> 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".
>
> Are you denying that this is a bug?  Are you denying that there’s a
> usability issue at hand?

I agree it's a usability issue.

> To me, what 宋文武 reported at the beginning of this thread is a
> usability issue.  We’ve hacked around it so far, but we know there are
> cases where the hacks aren’t enough.
>
> We could declare it as “won’t fix”, but I’m not comfortable with that.

No, no, I'm against “won't fix”.  I don't mind if it's called a bug, and
a solution you suggest is the best, but it suits only the default case
of a single user profile.  If I have several user profiles, it does
nothing useful for me, only wastes the time.

>>>> 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
>
> [...]
>
> I very well understand your concern, so thanks for chiming in.
> Please let’s also consider the bug at hand.

OK, for the bug at hand, invoking "guix package --search-paths" looks
like the only possible solution, but please don't commit this patch
without giving a user a chance to decide what to put in /etc/profile.

> The solution I came up with might be inadequate.  Then we need to come
> up with an alternate proposal, or to resign and mark it as “wontfix.”

It is adequate and I'm not against it.

> What would you suggest?

After all, I realized what is my main concern: "/etc/profile" is
non-editable.  If I don't like some pieces of this file, I can do
nothing, and I just have to live with it and suffer.  Ideally I would
like to decide what pieces I want to put in /etc/profile and what I
don't.  But it's probably not possible, so…

… what I suggest now is just to give an option to avoid generating the
default /etc/profile.  What about making an 'operating-system' field for
this file (similar to 'sudoers-file' or 'hosts-file')?  So when such
'profile-file' is specified, it will be used instead of the default one
(of course, it should be mentioned in the manual that it's only for
those users who are sure what they do).

If this 'profile-file' field appears, I will gladly use it, and I will
not object to any future changes in /etc/profile.

-- 
Alex

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-11-22 13:52 +0300) wrote:

[...]

>> To me, what 宋文武 reported at the beginning of this thread is a
>> usability issue.  We’ve hacked around it so far, but we know there are
>> cases where the hacks aren’t enough.
>>
>> We could declare it as “won’t fix”, but I’m not comfortable with that.
>
> No, no, I'm against “won't fix”.  I don't mind if it's called a bug, and
> a solution you suggest is the best,

OK.

> but it suits only the default case of a single user profile.  If I
> have several user profiles, it does nothing useful for me, only wastes
> the time.

I think this is fine.  ~/.guix-profile is treated specially in many
ways.  I think users do not expect other profiles to be magically taken
into account.

> OK, for the bug at hand, invoking "guix package --search-paths" looks
> like the only possible solution, but please don't commit this patch
> without giving a user a chance to decide what to put in /etc/profile.

OK.

>> The solution I came up with might be inadequate.  Then we need to come
>> up with an alternate proposal, or to resign and mark it as “wontfix.”
>
> It is adequate and I'm not against it.

OK.  To me, that it takes 2 seconds on your machines suggests that it’s
not great either.

>> What would you suggest?
>
> After all, I realized what is my main concern: "/etc/profile" is
> non-editable.  If I don't like some pieces of this file, I can do
> nothing, and I just have to live with it and suffer.  Ideally I would
> like to decide what pieces I want to put in /etc/profile and what I
> don't.  But it's probably not possible, so…
>
> … what I suggest now is just to give an option to avoid generating the
> default /etc/profile.  What about making an 'operating-system' field for
> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such
> 'profile-file' is specified, it will be used instead of the default one
> (of course, it should be mentioned in the manual that it's only for
> those users who are sure what they do).

I think we could make an /etc/profile-service that receives snippets
meant to be glued together into the final /etc/profile.  Users could
specify the top or bottom of the file.

There could be a combined-search-paths-service that implements the
solution I proposed here.

WDYT?

> If this 'profile-file' field appears, I will gladly use it, and I will
> not object to any future changes in /etc/profile.

Of course we want to offer this flexibility.  But I think it’s also
important to discuss the defaults, to make sure they are acceptable to
many and that they improve the “user experience.”

Thanks,
Ludo’.

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

[Alex Kost]

Ludovic Courtès (2015-11-23 02:04 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-11-22 13:52 +0300) wrote:
>
> [...]
>
>> but it suits only the default case of a single user profile.  If I
>> have several user profiles, it does nothing useful for me, only wastes
>> the time.
>
> I think this is fine.  ~/.guix-profile is treated specially in many
> ways.  I think users do not expect other profiles to be magically taken
> into account.

Yes, this is a good default option, all I wanted to say is if I don't
use Guix in a default way, I would like to change this default option to
suit my needs.

>>> What would you suggest?
>>
>> After all, I realized what is my main concern: "/etc/profile" is
>> non-editable.  If I don't like some pieces of this file, I can do
>> nothing, and I just have to live with it and suffer.  Ideally I would
>> like to decide what pieces I want to put in /etc/profile and what I
>> don't.  But it's probably not possible, so…
>>
>> … what I suggest now is just to give an option to avoid generating the
>> default /etc/profile.  What about making an 'operating-system' field for
>> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such
>> 'profile-file' is specified, it will be used instead of the default one
>> (of course, it should be mentioned in the manual that it's only for
>> those users who are sure what they do).
>
> I think we could make an /etc/profile-service that receives snippets
> meant to be glued together into the final /etc/profile.  Users could
> specify the top or bottom of the file.
>
> There could be a combined-search-paths-service that implements the
> solution I proposed here.
>
> WDYT?

I agree, the more ways to change a default behaviour, the better.
Although I will not use these things if there will be ‘profile-file’
field that allows to specify my own "/etc/profile".

>> If this 'profile-file' field appears, I will gladly use it, and I will
>> not object to any future changes in /etc/profile.
>
> Of course we want to offer this flexibility.

Great!  So is it OK to send a patch for adding ‘profile-file’ field?

>  But I think it’s also
> important to discuss the defaults, to make sure they are acceptable to
> many and that they improve the “user experience.”

I'm probably not the person to discuss the defaults, as very often I
find defaults inappropriate.  For example, invoking "guix package
--search-paths" in /etc/profile is a totally unacceptable default for
me (sorry for mentioning it all the time :-))

-- 
Alex

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-11-23 02:04 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2015-11-22 13:52 +0300) wrote:
>>
>> [...]
>>
>>> but it suits only the default case of a single user profile.  If I
>>> have several user profiles, it does nothing useful for me, only wastes
>>> the time.
>>
>> I think this is fine.  ~/.guix-profile is treated specially in many
>> ways.  I think users do not expect other profiles to be magically taken
>> into account.
>
> Yes, this is a good default option, all I wanted to say is if I don't
> use Guix in a default way, I would like to change this default option to
> suit my needs.

IMO this is beyond the scope of this discussion: /etc/profile already
sources ~/.guix-profile/etc/profile explicitly, and not anything else.

[...]

>>> … what I suggest now is just to give an option to avoid generating the
>>> default /etc/profile.  What about making an 'operating-system' field for
>>> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such
>>> 'profile-file' is specified, it will be used instead of the default one
>>> (of course, it should be mentioned in the manual that it's only for
>>> those users who are sure what they do).
>>
>> I think we could make an /etc/profile-service that receives snippets
>> meant to be glued together into the final /etc/profile.  Users could
>> specify the top or bottom of the file.
>>
>> There could be a combined-search-paths-service that implements the
>> solution I proposed here.
>>
>> WDYT?
>
> I agree, the more ways to change a default behaviour, the better.
> Although I will not use these things if there will be ‘profile-file’
> field that allows to specify my own "/etc/profile".

[...]

> Great!  So is it OK to send a patch for adding ‘profile-file’ field?

Hmm, I’m not sure if we want to give direct access to /etc/profile like
this.

The problem is that several things in there are here to make the system
work, and to to make it conform to the ‘operating-system’ declaration,
such as:

--8<---------------cut here---------------start------------->8---
export LANG="en_US.utf8"
export TZ="Europe/Paris"
export TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"

# Tell 'modprobe' & co. where to look for modules.
export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
--8<---------------cut here---------------end--------------->8---

The risk I see with adding a raw ‘profile-file’ option is that newcomers
may end up getting rid of such things without really noticing, and then
getting a broken system.

What about instead giving a way to populate the top and/or bottom of
this file?  Controversial parts, if any, could still be turned on and
off by adding or removing services that add these lines?

I think we should open a separate bug report to discuss this.

>>  But I think it’s also
>> important to discuss the defaults, to make sure they are acceptable to
>> many and that they improve the “user experience.”
>
> I'm probably not the person to discuss the defaults, as very often I
> find defaults inappropriate.

Understood.  I’m sure you’ll understand, though, that it’s in the
interest of the project and its users to provide a good user experience
firsthand.

Thanks for your feedback,
Ludo’.

Adding operating-system field for a custom /etc/profile.

[Alex Kost]

This is a continuation of the discussion beginning here:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44>.

To sum up: I would like to have a possibility to use my own /etc/profile
instead of the default one, but Ludovic doesn't want to provide me this
freedom :-(

Ludovic Courtès (2015-11-23 17:31 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-11-23 02:04 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
[...]
>>>> … what I suggest now is just to give an option to avoid generating the
>>>> default /etc/profile.  What about making an 'operating-system' field for
>>>> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such
>>>> 'profile-file' is specified, it will be used instead of the default one
>>>> (of course, it should be mentioned in the manual that it's only for
>>>> those users who are sure what they do).
>>>
>>> I think we could make an /etc/profile-service that receives snippets
>>> meant to be glued together into the final /etc/profile.  Users could
>>> specify the top or bottom of the file.
>>>
>>> There could be a combined-search-paths-service that implements the
>>> solution I proposed here.
>>>
>>> WDYT?
>>
>> I agree, the more ways to change a default behaviour, the better.
>> Although I will not use these things if there will be ‘profile-file’
>> field that allows to specify my own "/etc/profile".
>
> [...]
>
>> Great!  So is it OK to send a patch for adding ‘profile-file’ field?
>
> Hmm, I’m not sure if we want to give direct access to /etc/profile like
> this.

Oh, no!  If there is one person (me) who wants to have a full control on
his /etc/profile, there may be the others with the same wish.

> The problem is that several things in there are here to make the system
> work, and to to make it conform to the ‘operating-system’ declaration,
> such as:
>
>
> export LANG="en_US.utf8"
> export TZ="Europe/Paris"
> export TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"
>
> # Tell 'modprobe' & co. where to look for modules.
> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules

Yes, that's why I suggest to add a note to the manual about a danger of
using this field.

> The risk I see with adding a raw ‘profile-file’ option is that newcomers
> may end up getting rid of such things without really noticing, and then
> getting a broken system.

But a newcomer will learn about this option only if (s)he reads the
manual with the warning I've mentioned.  For me, your phrase sounds
like: «We will not provide "rm" command, because a newcomer may
accidentally run "rm -rf ~"».  Please give me an opportunity to shoot
myself in the foot!

Besides will the system really be broken?  What do you mean?  Even if
/etc/profile is empty, the system will boot successfully and a user
could login, no?

> What about instead giving a way to populate the top and/or bottom of
> this file?  Controversial parts, if any, could still be turned on and
> off by adding or removing services that add these lines?

It is better than nothing, but it is not sufficient IMO.  Any part of
/etc/profile can be controversial (you'll never know what a user would
like to change), so I think providing an option to change this file
completely is essential.

But I agree that appending/prepending some lines may also be useful for
those who like to keep the default /etc/profile and who just want to add
something to it.

> I think we should open a separate bug report to discuss this.

I agree that it's not related to this bug, so I'm sending this message
to guix-devel list.

-- 
Alex

Re: Adding operating-system field for a custom /etc/profile.

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-11-23 17:31 +0300) wrote:

[...]

>>> Great!  So is it OK to send a patch for adding ‘profile-file’ field?
>>
>> Hmm, I’m not sure if we want to give direct access to /etc/profile like
>> this.
>
> Oh, no!  If there is one person (me) who wants to have a full control on
> his /etc/profile, there may be the others with the same wish.
>
>> The problem is that several things in there are here to make the system
>> work, and to to make it conform to the ‘operating-system’ declaration,
>> such as:
>>
>>
>> export LANG="en_US.utf8"
>> export TZ="Europe/Paris"
>> export TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"
>>
>> # Tell 'modprobe' & co. where to look for modules.
>> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>
> Yes, that's why I suggest to add a note to the manual about a danger of
> using this field.
>
>> The risk I see with adding a raw ‘profile-file’ option is that newcomers
>> may end up getting rid of such things without really noticing, and then
>> getting a broken system.
>
> But a newcomer will learn about this option only if (s)he reads the
> manual with the warning I've mentioned.  For me, your phrase sounds
> like: «We will not provide "rm" command, because a newcomer may
> accidentally run "rm -rf ~"».  Please give me an opportunity to shoot
> myself in the foot!
>
> Besides will the system really be broken?

Yes.

> What do you mean?

I can already see the bug reports: “I specified the en_US.utf8 locale in
the declaration, but somehow I end up with the C locale”; “why doesn’t
modprobe find modules?”; “I’m stuck in the GMT timezone”, etc. etc.

And only after 5 messages will we learn that the user wanted to add
*one* line to /etc/profile, did that via the ‘profile-file’ field,
without noticing that this would wipe out all the rest of the useful
stuff from there.

> Even if /etc/profile is empty, the system will boot successfully and a
> user could login, no?

Sure, but merely booting is not sufficient.

>> What about instead giving a way to populate the top and/or bottom of
>> this file?  Controversial parts, if any, could still be turned on and
>> off by adding or removing services that add these lines?
>
> It is better than nothing, but it is not sufficient IMO.  Any part of
> /etc/profile can be controversial (you'll never know what a user would
> like to change), so I think providing an option to change this file
> completely is essential.
>
> But I agree that appending/prepending some lines may also be useful for
> those who like to keep the default /etc/profile and who just want to add
> something to it.

OK.

NixOS apparently takes in approach similar to that:

  https://github.com/NixOS/nixos/blob/master/modules/programs/bash/bash.nix

There’s a bunch of high-level options like ‘shellAliases’, ‘promptInit’,
etc. that get pasted in /etc/profile or /etc/bashrc.  In addition,
/etc/profile sources /etc/profile.local if available, and similarly for
/etc/bashrc.

‘shellInit’ in that file refers to ‘setEnvironment’, as defined here:

  https://github.com/NixOS/nixos/blob/master/modules/programs/environment.nix
  https://github.com/NixOS/nixos/blob/master/modules/config/shells-environment.nix

Interestingly, that part does like ‘guix package --search-paths’ as
suggested at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41>,
but does it in Bash and without stat’ing files.


Anyway, I think the way forward is to make /etc/profile modular in
similar fashion.  What about starting with an /etc/profile service that
can receive Bash snippets and paste them in the middle of the file,
right before:

  if [ -n "$BASH_VERSION" -a -f /etc/bashrc ]
  then
    # Load Bash-specific initialization code.
    . /etc/bashrc
  fi

Does that make sense?

I can give it a try if you want.

Thanks,
Ludo’.

Re: Adding operating-system field for a custom /etc/profile.

[Alex Kost]

Ludovic Courtès (2015-11-24 15:48 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-11-23 17:31 +0300) wrote:
>
> [...]
>
>>>> Great!  So is it OK to send a patch for adding ‘profile-file’ field?
>>>
>>> Hmm, I’m not sure if we want to give direct access to /etc/profile like
>>> this.
>>
>> Oh, no!  If there is one person (me) who wants to have a full control on
>> his /etc/profile, there may be the others with the same wish.
>>
>>> The problem is that several things in there are here to make the system
>>> work, and to to make it conform to the ‘operating-system’ declaration,
>>> such as:
>>>
>>>
>>> export LANG="en_US.utf8"
>>> export TZ="Europe/Paris"
>>> export
>>> TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"
>>>
>>> # Tell 'modprobe' & co. where to look for modules.
>>> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>>
>> Yes, that's why I suggest to add a note to the manual about a danger of
>> using this field.
>>
>>> The risk I see with adding a raw ‘profile-file’ option is that newcomers
>>> may end up getting rid of such things without really noticing, and then
>>> getting a broken system.
>>
>> But a newcomer will learn about this option only if (s)he reads the
>> manual with the warning I've mentioned.  For me, your phrase sounds
>> like: «We will not provide "rm" command, because a newcomer may
>> accidentally run "rm -rf ~"».  Please give me an opportunity to shoot
>> myself in the foot!
>>
>> Besides will the system really be broken?
>
> Yes.

I don't agree with your points, so it is "No" for me.

>> What do you mean?
>
> I can already see the bug reports: “I specified the en_US.utf8 locale in
> the declaration, but somehow I end up with the C locale”; “why doesn’t
> modprobe find modules?”; “I’m stuck in the GMT timezone”, etc. etc.
>
> And only after 5 messages will we learn that the user wanted to add
> *one* line to /etc/profile, did that via the ‘profile-file’ field,
> without noticing that this would wipe out all the rest of the useful
> stuff from there.

Sorry again, but I read: «No, no, we really shouldn't provide "rm"
command, because it can do a big harm!»  If a user just blindly puts
something in his operating-system declaration or runs "rm -rf ~", then
(s)he deserves the harm (s)he gets.

>>> What about instead giving a way to populate the top and/or bottom of
>>> this file?  Controversial parts, if any, could still be turned on and
>>> off by adding or removing services that add these lines?
>>
>> It is better than nothing, but it is not sufficient IMO.  Any part of
>> /etc/profile can be controversial (you'll never know what a user would
>> like to change), so I think providing an option to change this file
>> completely is essential.
>>
>> But I agree that appending/prepending some lines may also be useful for
>> those who like to keep the default /etc/profile and who just want to add
>> something to it.
>
> OK.
>
> NixOS apparently takes in approach similar to that:
>
>   https://github.com/NixOS/nixos/blob/master/modules/programs/bash/bash.nix
>
> There’s a bunch of high-level options like ‘shellAliases’, ‘promptInit’,
> etc. that get pasted in /etc/profile or /etc/bashrc.  In addition,
> /etc/profile sources /etc/profile.local if available, and similarly for
> /etc/bashrc.
>
> ‘shellInit’ in that file refers to ‘setEnvironment’, as defined here:
>
>   https://github.com/NixOS/nixos/blob/master/modules/programs/environment.nix
>   https://github.com/NixOS/nixos/blob/master/modules/config/shells-environment.nix
>
> Interestingly, that part does like ‘guix package --search-paths’ as
> suggested at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41>,
> but does it in Bash and without stat’ing files.

Thanks for this NixOS info!

> Anyway, I think the way forward is to make /etc/profile modular in
> similar fashion.  What about starting with an /etc/profile service that
> can receive Bash snippets and paste them in the middle of the file,
> right before:
>
>   if [ -n "$BASH_VERSION" -a -f /etc/bashrc ]
>   then
>     # Load Bash-specific initialization code.
>     . /etc/bashrc
>   fi
>
> Does that make sense?

I agree that a modular /etc/profile would be great, but only if *any*
part of it can be changed or removed, otherwise this decision will have
the same problem: one day there will appear users who would like to
change the parts that cannot be changed.

But still I prefer to have a straightforward way to set my own
/etc/profile.  Or maybe it would be good to have even a more general
solution: a way to specify any file that goes to "/etc" dir, something
like this:

(operating-system
  ;; ...
  (etc-files
   ("hosts"   (local-file "/home/me/guix/etc/hosts"))
   ("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile"))
   ("fstab"   (local-file "/home/me/guix/etc/fstab"))))

You will probably consider this decision evil, but for me it's a perfect
solution.  As I see it:

- these 'etc-files' should have a priority over the default generated
  /etc files;

- "guix system" command should report if these files override the
  default ones, and it can even create "/etc/foobar.default" so that a
  user could look at it any time;

- and of course the manual should warn that 'etc-files' is a very
  dangerous option, blah, blah, blah.

The most valuable thing for me is customizability, and I just can't
stand the situation when developers refuse to provide a way to customize
defaults for no reason (or just because it is potentially dangerous).

I don't like the default grub.cfg, but I've never complained about it
because there is "--no-grub" option, so I can install grub on my own and
use my own grub config.  This is great! :-)

The problem with /etc files, is that they can't be edited directly, and
operating-system doesn't provide a way to change any aspect of these
files, so I always find things that I don't like and that can't be
changed.  This is bad! :-(

> I can give it a try if you want.

Sorry, but this is not what I want.  I would like to have a full control
on any aspect of my system.

-- 
Alex

Re: Adding operating-system field for a custom /etc/profile.

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-11-24 15:48 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:

[...]

>>> Besides will the system really be broken?
>>
>> Yes.
>
> I don't agree with your points, so it is "No" for me.

Alex, this is unproductive.  Please let’s get back to work now.

>> Anyway, I think the way forward is to make /etc/profile modular in
>> similar fashion.  What about starting with an /etc/profile service that
>> can receive Bash snippets and paste them in the middle of the file,
>> right before:
>>
>>   if [ -n "$BASH_VERSION" -a -f /etc/bashrc ]
>>   then
>>     # Load Bash-specific initialization code.
>>     . /etc/bashrc
>>   fi
>>
>> Does that make sense?
>
> I agree that a modular /etc/profile would be great, but only if *any*
> part of it can be changed or removed, otherwise this decision will have
> the same problem: one day there will appear users who would like to
> change the parts that cannot be changed.
>
> But still I prefer to have a straightforward way to set my own
> /etc/profile.  Or maybe it would be good to have even a more general
> solution: a way to specify any file that goes to "/etc" dir, something
> like this:
>
> (operating-system
>   ;; ...
>   (etc-files
>    ("hosts"   (local-file "/home/me/guix/etc/hosts"))
>    ("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile"))
>    ("fstab"   (local-file "/home/me/guix/etc/fstab"))))

Please take a look at ‘etc-service’.  It’s essentially what you describe.

> You will probably consider this decision evil, but for me it's a perfect
> solution.

For you, understood.

> Sorry, but this is not what I want.  I would like to have a full control
> on any aspect of my system.

I think you’re overreacting.  I feel bad because in spite of several
attempts, I’m failing to get us to focus on concrete proposal to move
forward.  I don’t know what to add.

Ludo’.

Re: Adding operating-system field for a custom /etc/profile.

[Alex Kost]

Ludovic Courtès (2015-11-24 23:30 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
[...]
>> But still I prefer to have a straightforward way to set my own
>> /etc/profile.  Or maybe it would be good to have even a more general
>> solution: a way to specify any file that goes to "/etc" dir, something
>> like this:
>>
>> (operating-system
>>   ;; ...
>>   (etc-files
>>    ("hosts"   (local-file "/home/me/guix/etc/hosts"))
>>    ("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile"))
>>    ("fstab"   (local-file "/home/me/guix/etc/fstab"))))
>
> Please take a look at ‘etc-service’.  It’s essentially what you describe.

Yes I know, I mean this is what I would like to have, but it can't be
used right now.  As ‘operating-system-etc-service’ is a part of
‘essential-services’, it cannot be modified/replaced, right?  I see that
now operating-system services are split into 'essential-services' and
'user-services'.  What about letting a user change any service instead?
I mean to make %essential-services and make it a part of %base-services.
(I didn't look in the details though, so I don't know if it's possible.)

>> Sorry, but this is not what I want.  I would like to have a full control
>> on any aspect of my system.
>
> I think you’re overreacting.  I feel bad because in spite of several
> attempts, I’m failing to get us to focus on concrete proposal to move
> forward.  I don’t know what to add.

I'm sorry for being so emotional; that's because I don't want to return
to "Arch Linux"!  I love GuixSD, but this is a potential blocker for me.
I just tried to explain that users may want to change/replace any
/etc/<file>, but they can't do it (this is essential for me, as I have a
sick wish to control everything).

Sorry, but your proposal is only a solution for this particular
--search-paths thing.  There are (and will be) other places in /etc
files that are not covered by 'operating-system' fields.  Ideally I
would like to have a possibility to override /etc/<file> if
'operating-system' does not allow me to change it the way I want.

-- 
Alex

Re: Adding operating-system field for a custom /etc/profile.

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-11-24 23:30 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
> [...]
>>> But still I prefer to have a straightforward way to set my own
>>> /etc/profile.  Or maybe it would be good to have even a more general
>>> solution: a way to specify any file that goes to "/etc" dir, something
>>> like this:
>>>
>>> (operating-system
>>>   ;; ...
>>>   (etc-files
>>>    ("hosts"   (local-file "/home/me/guix/etc/hosts"))
>>>    ("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile"))
>>>    ("fstab"   (local-file "/home/me/guix/etc/fstab"))))
>>
>> Please take a look at ‘etc-service’.  It’s essentially what you describe.
>
> Yes I know, I mean this is what I would like to have, but it can't be
> used right now.  As ‘operating-system-etc-service’ is a part of
> ‘essential-services’, it cannot be modified/replaced, right?  I see that
> now operating-system services are split into 'essential-services' and
> 'user-services'.  What about letting a user change any service instead?
> I mean to make %essential-services and make it a part of %base-services.
> (I didn't look in the details though, so I don't know if it's possible.)

Yeah it’s not that simple, because <operating-system> objects
essentially get compiled down to a list of <service>; some of them are
added as a function of what the <operating-system> object contains.

But see my other proposal about “Customizing /etc.”

>>> Sorry, but this is not what I want.  I would like to have a full control
>>> on any aspect of my system.
>>
>> I think you’re overreacting.  I feel bad because in spite of several
>> attempts, I’m failing to get us to focus on concrete proposal to move
>> forward.  I don’t know what to add.
>
> I'm sorry for being so emotional; that's because I don't want to return
> to "Arch Linux"!  I love GuixSD, but this is a potential blocker for me.
> I just tried to explain that users may want to change/replace any
> /etc/<file>, but they can't do it (this is essential for me, as I have a
> sick wish to control everything).

Understood!

Please bear with me/us.  This is an iterative process.  Think of what
GuixSD was like 6 months ago.  ;-)  Initially, many things had to be more
or less hardcoded to allow us to get something running, in turn making
it possible to do more development and to refine things.

You’re pointing at limitations that have always been there and that need
to be addressed.  The mere fact that we can have heated discussions over
these features means we’ve already done a lot of progress technically.
:-)

And again, rest assured that there’s no fundamental disagreement between
us on the goals.  It’s just about finding the right approach to satisfy
all the (sometimes contradictory) needs.

Thank you,
Ludo’.

Re: Adding operating-system field for a custom /etc/profile.

[宋文武]

On 2015-11-24 04:07, Alex Kost wrote:
> This is a continuation of the discussion beginning here:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44>.
> 
> To sum up: I would like to have a possibility to use my own 
> /etc/profile
> instead of the default one, but Ludovic doesn't want to provide me this
> freedom :-(
Well, every comment in /etc/profile came with a hack which make
something work.  but it's becomming big and hard to understand every 
line.

> 
> Ludovic Courtès (2015-11-23 17:31 +0300) wrote:
> 
>> Alex Kost <alezost@gmail.com> skribis:
>> 
>>> Ludovic Courtès (2015-11-23 02:04 +0300) wrote:
>>> 
>>>> Alex Kost <alezost@gmail.com> skribis:
> [...]
>>>>> … what I suggest now is just to give an option to avoid generating 
>>>>> the
>>>>> default /etc/profile.  What about making an 'operating-system' 
>>>>> field for
>>>>> this file (similar to 'sudoers-file' or 'hosts-file')?  So when 
>>>>> such
>>>>> 'profile-file' is specified, it will be used instead of the default 
>>>>> one
>>>>> (of course, it should be mentioned in the manual that it's only for
>>>>> those users who are sure what they do).
>>>> 
>>>> I think we could make an /etc/profile-service that receives snippets
>>>> meant to be glued together into the final /etc/profile.  Users could
>>>> specify the top or bottom of the file.
>>>> 
>>>> There could be a combined-search-paths-service that implements the
>>>> solution I proposed here.
>>>> 
>>>> WDYT?
>>> 
>>> I agree, the more ways to change a default behaviour, the better.
>>> Although I will not use these things if there will be ‘profile-file’
>>> field that allows to specify my own "/etc/profile".
>> 
>> [...]
>> 
>>> Great!  So is it OK to send a patch for adding ‘profile-file’ field?
>> 
>> Hmm, I’m not sure if we want to give direct access to /etc/profile 
>> like
>> this.
> 
> Oh, no!  If there is one person (me) who wants to have a full control 
> on
> his /etc/profile, there may be the others with the same wish.
Sure, I think we all want (and should have) a full control.

> 
>> The problem is that several things in there are here to make the 
>> system
>> work, and to to make it conform to the ‘operating-system’ declaration,
>> such as:
>> 
>> 
>> export LANG="en_US.utf8"
>> export TZ="Europe/Paris"
>> export 
>> TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"
>> 
>> # Tell 'modprobe' & co. where to look for modules.
>> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
> 
> Yes, that's why I suggest to add a note to the manual about a danger of
> using this field.
> 
>> The risk I see with adding a raw ‘profile-file’ option is that 
>> newcomers
>> may end up getting rid of such things without really noticing, and 
>> then
>> getting a broken system.
> 
> But a newcomer will learn about this option only if (s)he reads the
> manual with the warning I've mentioned.  For me, your phrase sounds
> like: «We will not provide "rm" command, because a newcomer may
> accidentally run "rm -rf ~"».  Please give me an opportunity to shoot
> myself in the foot!
> 
> Besides will the system really be broken?  What do you mean?  Even if
> /etc/profile is empty, the system will boot successfully and a user
> could login, no?
Yes, login works, but then /run/current-system/profile/bin isn't in
PATH, and some system configurations (eg: locale, timezone) are ignored.

> 
>> What about instead giving a way to populate the top and/or bottom of
>> this file?  Controversial parts, if any, could still be turned on and
>> off by adding or removing services that add these lines?
> 
> It is better than nothing, but it is not sufficient IMO.  Any part of
> /etc/profile can be controversial (you'll never know what a user would
> like to change), so I think providing an option to change this file
> completely is essential.
To be clear, /etc/profile contains 3 parts:

  1. variables from configuration of the operating-system (LANG, TZ, 
etc.)
  2. environment setup for system and user profiles
     (source .guix-profile/etc/profile)
  3. hacks for making sensible defaults (LINUX_MODULE_DIRECTORY,
     ASPELL_CONF, etc).

And it's only effective for POSIX login shells (bash and zsh).

For 1, maybe the most important one, it's already managed, but doesn't
work for fish and rc.  We need to move these into /etc/environment,
which work for all shells (even emacs? :-)

I had recall my tries, but at that time only zsh was considered.
<https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00674.html>


For 2, we had build a etc/profile file for each profile's search-paths,
here source both system and user to make most things work 
out-of-the-box.

I think this is the real purpose for our /etc/profile.
Technical, if we remove those, the result system will be the same as
guix on foreign distros.  So, it's ok to completely replace it.

(some variables (eg: MANPATH, INFOPATH, XDG_DATA_DIRS) can be set in
each profile, and mergerd well).


And 3, IMO is the controversial parts.

the one don't related to profiles can go into /etc/environment
(eg: LINUX_MODULE_DIRECTORY, SSL_CERT_DIR, DBUS_FATAL_WARNINGS),
these need to be addressing by adding services?

and others may go into profile (eg: ASPELL_CONF, GST_PLUGIN_PATH).


So, the plan is add /etc/environment and only use /etc/profile for 2.
then, a sh-profile file-like configuration can be added.  WDYT?

Re: Adding operating-system field for a custom /etc/profile.

[Alex Kost]

宋文武 (2015-11-24 18:22 +0300) wrote:

> On 2015-11-24 04:07, Alex Kost wrote:
>> This is a continuation of the discussion beginning here:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44>.
>>
>> To sum up: I would like to have a possibility to use my own
>> /etc/profile
>> instead of the default one, but Ludovic doesn't want to provide me this
>> freedom :-(
> Well, every comment in /etc/profile came with a hack which make
> something work.  but it's becomming big and hard to understand every
> line.

Sorry, I don't understand what you want to say.  I'm able to make my own
/etc/profile based on the default one, and I just want to have an option
to do it.

>> Ludovic Courtès (2015-11-23 17:31 +0300) wrote:
>>
>>> Hmm, I’m not sure if we want to give direct access to /etc/profile
>>> like
>>> this.
>>
>> Oh, no!  If there is one person (me) who wants to have a full control
>> on
>> his /etc/profile, there may be the others with the same wish.
> Sure, I think we all want (and should have) a full control.

Yes, unluckily GuixSD does not provide such control currently.

[...]
>>> The risk I see with adding a raw ‘profile-file’ option is that
>>> newcomers
>>> may end up getting rid of such things without really noticing, and
>>> then
>>> getting a broken system.
>>
>> But a newcomer will learn about this option only if (s)he reads the
>> manual with the warning I've mentioned.  For me, your phrase sounds
>> like: «We will not provide "rm" command, because a newcomer may
>> accidentally run "rm -rf ~"».  Please give me an opportunity to shoot
>> myself in the foot!
>>
>> Besides will the system really be broken?  What do you mean?  Even if
>> /etc/profile is empty, the system will boot successfully and a user
>> could login, no?
> Yes, login works, but then /run/current-system/profile/bin isn't in
> PATH, and some system configurations (eg: locale, timezone) are ignored.

Yes, but we are talking about an optional thing, that should be
explicitly set by a user, so I don't really understand concerns about
the potential risk, as a user will learn about this option at first
before using it.

>>> What about instead giving a way to populate the top and/or bottom of
>>> this file?  Controversial parts, if any, could still be turned on and
>>> off by adding or removing services that add these lines?
>>
>> It is better than nothing, but it is not sufficient IMO.  Any part of
>> /etc/profile can be controversial (you'll never know what a user would
>> like to change), so I think providing an option to change this file
>> completely is essential.
> To be clear, /etc/profile contains 3 parts:
>
>  1. variables from configuration of the operating-system (LANG, TZ,
> etc.)
>  2. environment setup for system and user profiles
>     (source .guix-profile/etc/profile)
>  3. hacks for making sensible defaults (LINUX_MODULE_DIRECTORY,
>     ASPELL_CONF, etc).
>
> And it's only effective for POSIX login shells (bash and zsh).
>
> For 1, maybe the most important one, it's already managed, but doesn't
> work for fish and rc.  We need to move these into /etc/environment,
> which work for all shells (even emacs? :-)

I didn't know about /etc/environment.  So IIUC it is used for VAR=VALUE
pairs, right?  If so and if it is supported by all shells (I don't see a
mention of it in the bash manual though), I agree with you to move these
things, great idea!

> For 2, we had build a etc/profile file for each profile's search-paths,
> here source both system and user to make most things work
> out-of-the-box.
>
> I think this is the real purpose for our /etc/profile.
> Technical, if we remove those, the result system will be the same as
> guix on foreign distros.  So, it's ok to completely replace it.
>
> (some variables (eg: MANPATH, INFOPATH, XDG_DATA_DIRS) can be set in
> each profile, and mergerd well).

IIUC invoking "guix package --search-paths" on both system and user
profiles sets all required environment variables, so sourcing
/run/current-system/profile/etc/profile and ~/.guix-profile/etc/profile
is not needed, right?

> And 3, IMO is the controversial parts.
>
> the one don't related to profiles can go into /etc/environment
> (eg: LINUX_MODULE_DIRECTORY, SSL_CERT_DIR, DBUS_FATAL_WARNINGS),
> these need to be addressing by adding services?

I agree that it's better to put plain VAR=VAL to /etc/environment.

> and others may go into profile (eg: ASPELL_CONF, GST_PLUGIN_PATH).

Yes.  And this is another example of the thing I want to change: I don't
like to have any mention of "$HOME/.guix-profile" in /etc/profile, so I
would remove these things it if had a chance.

> So, the plan is add /etc/environment and only use /etc/profile for 2.
> then, a sh-profile file-like configuration can be added.  WDYT?

I like the idea of separating /etc/environment and /etc/profile, but my
main concern is to have a possibility to change /etc files the way I
want, as I explained in the reply to Ludovic.

-- 
Alex

Customizing /etc

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> 宋文武 (2015-11-24 18:22 +0300) wrote:

[...]

>> So, the plan is add /etc/environment and only use /etc/profile for 2.
>> then, a sh-profile file-like configuration can be added.  WDYT?
>
> I like the idea of separating /etc/environment and /etc/profile, but my
> main concern is to have a possibility to change /etc files the way I
> want, as I explained in the reply to Ludovic.

I agree that specifying what goes into /etc is something we want to
allow (though not directly related to the /etc/profile issue.)

What about exposing the name/file-like pairs that are passed to
‘etc-service’?  That way, one could write:

  (define os
    (operating-system
      ;; …
      (etc-files `(("hosts" ,(local-file "my-hosts-file"))
                   ("issue" ,(plain-file "Hello!\n"))
                   ("sudoers" ,(local-file "sudoers"))
                   ("profile" ,(local-file "myprofile"))
                   ,@(fold alist-delete
                           (default-etc-files os)
                           '("hosts" "issue" "sudoers" "profile"))))))

We may remove the ‘hosts-file’ and ‘sudoers-file’ fields, but keep
higher-level things like ‘name-service-switch’ because they’re more
convenient.

The difficulty is that some of the default files, such as /etc/hosts,
are generated as a function of the ‘operating-system’ declaration.  Thus
I think we need ‘default-etc-files’ to be a procedure as shown above,
and the ‘etc-files’ field must be thunked or delayed.  Hmm not fully
sure this is the right interface.

WDYT?

The bottom line is that /etc is not a great configuration interface
because it’s all flat and GuixSD has no idea of the meaning of those
files and their relationship.  So the preferred approach remains
configuration via services and high-level configuration objects.

Thanks,
Ludo’.

Re: Customizing /etc

[Alex Kost]

Ludovic Courtès (2015-11-27 17:58 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
[...]
>> I like the idea of separating /etc/environment and /etc/profile, but my
>> main concern is to have a possibility to change /etc files the way I
>> want, as I explained in the reply to Ludovic.
>
> I agree that specifying what goes into /etc is something we want to
> allow (though not directly related to the /etc/profile issue.)

Oof, that's a relief for me!  I had an impression that you are against
giving a user a full control over /etc files.

> What about exposing the name/file-like pairs that are passed to
> ‘etc-service’?  That way, one could write:
>
>   (define os
>     (operating-system
>       ;; …
>       (etc-files `(("hosts" ,(local-file "my-hosts-file"))
>                    ("issue" ,(plain-file "Hello!\n"))
>                    ("sudoers" ,(local-file "sudoers"))
>                    ("profile" ,(local-file "myprofile"))
>                    ,@(fold alist-delete
>                            (default-etc-files os)
>                            '("hosts" "issue" "sudoers" "profile"))))))

Yes, changing /etc files is exactly what I want!

> We may remove the ‘hosts-file’ and ‘sudoers-file’ fields, but keep
> higher-level things like ‘name-service-switch’ because they’re more
> convenient.

Yes, I agree; if this will be accepted, keeping '<foo>-file' fields (for
hosts, sudoers and future files) is probably not needed.

> The difficulty is that some of the default files, such as /etc/hosts,
> are generated as a function of the ‘operating-system’ declaration.  Thus
> I think we need ‘default-etc-files’ to be a procedure as shown above,
> and the ‘etc-files’ field must be thunked or delayed.  Hmm not fully
> sure this is the right interface.
>
> WDYT?

Yes, this will probably not be an easy-to-use interface, but to have it
is better than to have nothing.  So I am totally for it!

> The bottom line is that /etc is not a great configuration interface
> because it’s all flat and GuixSD has no idea of the meaning of those
> files and their relationship.  So the preferred approach remains
> configuration via services and high-level configuration objects.

Yes, I agree; but if a user is not satisfied by the result of these
high-level services, I think (s)he should have a fallback way to
change/override the resulting /etc file.

-- 
Alex

/etc/environment and /etc/profile

[Ludovic Courtès]

宋文武 <iyzsong@openmailbox.org> skribis:

> On 2015-11-24 04:07, Alex Kost wrote:

[...]

>> Oh, no!  If there is one person (me) who wants to have a full
>> control on
>> his /etc/profile, there may be the others with the same wish.
> Sure, I think we all want (and should have) a full control.

Agreed.

> To be clear, /etc/profile contains 3 parts:
>
>  1. variables from configuration of the operating-system (LANG, TZ,
> etc.)
>  2. environment setup for system and user profiles
>     (source .guix-profile/etc/profile)
>  3. hacks for making sensible defaults (LINUX_MODULE_DIRECTORY,
>     ASPELL_CONF, etc).
>
> And it's only effective for POSIX login shells (bash and zsh).
>
> For 1, maybe the most important one, it's already managed, but doesn't
> work for fish and rc.  We need to move these into /etc/environment,
> which work for all shells (even emacs? :-)

Using /etc/environment sounds like a good idea!  IIUC, it requires using
pam_env, right?  Do you know exactly what it would take?

> For 2, we had build a etc/profile file for each profile's search-paths,
> here source both system and user to make most things work
> out-of-the-box.
>
> I think this is the real purpose for our /etc/profile.
> Technical, if we remove those, the result system will be the same as
> guix on foreign distros.  So, it's ok to completely replace it.
>
> (some variables (eg: MANPATH, INFOPATH, XDG_DATA_DIRS) can be set in
> each profile, and mergerd well).

Yeah, I assume it’s fine to let that one be completely overridden.  The
documentation would have to clearly explain what the default file
contains, and what’s at stake if you remove it.

> And 3, IMO is the controversial parts.
>
> the one don't related to profiles can go into /etc/environment
> (eg: LINUX_MODULE_DIRECTORY, SSL_CERT_DIR, DBUS_FATAL_WARNINGS),
> these need to be addressing by adding services?
>
> and others may go into profile (eg: ASPELL_CONF, GST_PLUGIN_PATH).

Yes.

> So, the plan is add /etc/environment and only use /etc/profile for 2.
> then, a sh-profile file-like configuration can be added.  WDYT?

Sounds like a reasonable plan to me.

I can start work in that direction, but I’m also happy if you or someone
else gives it a try.

Thanks for your very clear analysis!

Ludo’.

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

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

[...]

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

Could you measure again after cc3de1d?

As it turns out, ‘guix package’ loads way too much and also stats too
much, at least for simple operations like --search-paths.

Thanks,
Ludo’.

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

[Alex Kost]

Ludovic Courtès (2015-11-24 20:22 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-11-21 23:10 +0300) wrote:
>
> [...]
>
>>> 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
>
> Could you measure again after cc3de1d?
>
> As it turns out, ‘guix package’ loads way too much and also stats too
> much, at least for simple operations like --search-paths.

real	0m1.122s
user	0m0.244s
sys	0m0.044s

I measured it several times with a "cold" HDD (I mean when appropriate
files were not cached), and the real time was always 1.0—1.3s.  Big
improvement!  Thank you very much for this, autoloads are great!

-- 
Alex

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

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-11-24 20:22 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2015-11-21 23:10 +0300) wrote:
>>
>> [...]
>>
>>>> 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
>>
>> Could you measure again after cc3de1d?
>>
>> As it turns out, ‘guix package’ loads way too much and also stats too
>> much, at least for simple operations like --search-paths.
>
> real	0m1.122s
> user	0m0.244s
> sys	0m0.044s
>
> I measured it several times with a "cold" HDD (I mean when appropriate
> files were not cached), and the real time was always 1.0—1.3s.  Big
> improvement!  Thank you very much for this, autoloads are great!

Great, thanks for testing!  That’s still too much to my state, but it’s
already an improvement.

Ludo’.

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

[Ludovic Courtès]

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

宋文武 <iyzsong@gmail.com> skribis:

> Or better to generate a 'profile' script for each manifest, and then
> merged in shell level, so it can work out-of-the-box. How about:
>   - /etc/profile:
>     # configuration for the whole system goes here.
>     # shouldn't refer profile paths.
>     export LANG=en_US.utf8
>     export SSL_CERT_DIR=/etc/ssl/certs
>     export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>     [...]
>
>     source /run/current-system/profile/etc/profile
>
>     if [ -f $HOME/.guix-profile/etc/profile ]; then
>       source $HOME/.guix-profile/etc/profile
>     fi
>
>     # honor setuid-programs
>     export PATH=/run/setuid-programs:$PATH
>
>   - /run/current-system/profile/etc/profile:
>     export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH
>     export MANPATH=/run/current-system/profile/share/man:$PATH
>     [...]
>     
>   - ~/.guix-profile/etc/profile:
>     export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH
>     [...]

There’s a further complication here: ‘profile-derivation’, which builds
the profile, doesn’t know its user-visible name ~/.guix-profile.  It
just knows its store file name.  However, we don’t want etc/profile to
read:

  export PATH=/gnu/store/...-profile/bin:$PATH

because then, the user’s environment variables in a running session
would keep pointing to a given profile generation.

So we have to tell ‘profile-generation’ what the user-visible name of
the profile is going to be.  Attached is a very rough patch to do that.
This is not so nice because all user interfaces will now have to pass
that #:target parameter or etc/profile will be “wrong.”

Another option would be to simply run:

  eval `guix package -p ~/.guix-profile --search-paths`

This has two downsides:

  1. It takes ~200 ms to run on my laptop, which can maybe be
     noticeable; OTOH it’s only for interactive shells, so maybe that’s
     OK.

  2. If there’s a manifest format change and /etc/profile calls a ‘guix’
     command that cannot handle the manifest format (because it’s older
     than the ‘guix’ used to build the profile), then it doesn’t work at
     all (that’s a bit contrived, but not completely impossible.)

Thoughts?

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 5178 bytes --]

	Modified   guix/profiles.scm
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 8445e00..308dc23 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -582,10 +582,15 @@ MANIFEST.  Single-file bundles are required by programs such as Git and Lynx."
 
 (define* (profile-derivation manifest
                              #:key
+                             target
                              (hooks %default-profile-hooks))
   "Return a derivation that builds a profile (aka. 'user environment') with
 the given MANIFEST.  The profile includes additional derivations returned by
-the monadic procedures listed in HOOKS--such as an Info 'dir' file, etc."
+the monadic procedures listed in HOOKS--such as an Info 'dir' file, etc.
+
+When TARGET is not #f, it must be a string denoting the file name under which
+the profile will be available--e.g., \"/home/rms/.guix-profile\".  This name
+is used in the profile's 'etc/profile' file (read that again.)"
   (mlet %store-monad ((extras (if (null? (manifest-entries manifest))
                                   (return '())
                                   (sequence %store-monad
@@ -598,20 +603,72 @@ the monadic procedures listed in HOOKS--such as an Info 'dir' file, etc."
 
     (define builder
       #~(begin
-          (use-modules (ice-9 pretty-print)
-                       (guix build union))
+          (use-modules (ice-9 match)
+                       (ice-9 regex)
+                       (ice-9 pretty-print)
+                       (guix build union)
+                       (guix build utils)
+                       (guix search-paths))
+
+          (define target
+            '#$target)
+
+          (define search-paths
+            (map sexp->search-path-specification
+                 '#$(map search-path-specification->sexp
+                         (append-map manifest-entry-search-paths
+                                     (manifest-entries manifest)))))
+
+          (define (use-target value separator)
+            (let ((items ((@@ (guix search-paths) string-tokenize*)
+                          value separator)))
+              (string-join (map (lambda (str)
+                                  (string-append target
+                                                 (string-drop str
+                                                              (string-length
+                                                               #$output))))
+                                items)
+                           separator)))
+
+          (define write-environment-variable-definition
+            (match-lambda
+              ((spec . value)
+               (let ((variable (search-path-specification-variable spec))
+                     (sep      (search-path-specification-separator spec)))
+                 (display
+                  (environment-variable-definition variable
+                                                   (if target
+                                                       (use-target value sep)
+                                                       value)
+                                                   #:separator sep
+                                                   #:kind 'prefix))
+                 (newline)))))
 
           (setvbuf (current-output-port) _IOLBF)
           (setvbuf (current-error-port) _IOLBF)
 
+          ;; Make the symlinks.
           (union-build #$output '#$inputs
                        #:log-port (%make-void-port "w"))
+
+          ;; Store meta-data.
           (call-with-output-file (string-append #$output "/manifest")
             (lambda (p)
-              (pretty-print '#$(manifest->gexp manifest) p)))))
+              (pretty-print '#$(manifest->gexp manifest) p)))
+
+          ;; Store a ready-to-use Bash profile.
+          (mkdir-p (string-append #$output "/etc"))
+          (with-output-to-file (string-append #$output "/etc/profile")
+            (lambda ()
+              (let ((variables (evaluate-search-paths search-paths #$output)))
+                (for-each write-environment-variable-definition
+                          variables))))))
 
     (gexp->derivation "profile" builder
-                      #:modules '((guix build union))
+                      #:modules '((guix build union)
+                                  (guix build utils)
+                                  (guix search-paths)
+                                  (guix records))
                       #:local-build? #t)))
 
 (define (profile-regexp profile)
	Modified   guix/scripts/package.scm
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 7f53af7..38ec8ed 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -833,6 +833,7 @@ more information.~%"))
                (let* ((prof-drv (run-with-store (%store)
                                   (profile-derivation
                                    new
+                                   #:target (user-friendly-profile profile)
                                    #:hooks (if bootstrap?
                                                '()
                                                %default-profile-hooks))))

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

[宋文武]

Ludovic Courtès <ludo@gnu.org> writes:

> 宋文武 <iyzsong@gmail.com> skribis:
>
>> Or better to generate a 'profile' script for each manifest, and then
>> merged in shell level, so it can work out-of-the-box. How about:
>>   - /etc/profile:
>>     # configuration for the whole system goes here.
>>     # shouldn't refer profile paths.
>>     export LANG=en_US.utf8
>>     export SSL_CERT_DIR=/etc/ssl/certs
>>     export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>>     [...]
>>
>>     source /run/current-system/profile/etc/profile
>>
>>     if [ -f $HOME/.guix-profile/etc/profile ]; then
>>       source $HOME/.guix-profile/etc/profile
>>     fi
>>
>>     # honor setuid-programs
>>     export PATH=/run/setuid-programs:$PATH
>>
>>   - /run/current-system/profile/etc/profile:
>>     export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH
>>     export MANPATH=/run/current-system/profile/share/man:$PATH
>>     [...]
>>     
>>   - ~/.guix-profile/etc/profile:
>>     export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH
>>     [...]
>
> There’s a further complication here: ‘profile-derivation’, which builds
> the profile, doesn’t know its user-visible name ~/.guix-profile.  It
> just knows its store file name.  However, we don’t want etc/profile to
> read:
>
>   export PATH=/gnu/store/...-profile/bin:$PATH
>
> because then, the user’s environment variables in a running session
> would keep pointing to a given profile generation.
Indeed.  Run guix to install a package should make it available
immediately.  Currently, we have 'PATH=~/.guix-profile/bin' in
profile and print hint for additional variables.
(Note that when profile changes, even we build all variables with the
location they going to be, a hint or re-source is still needed when the
new profile bring new variables.)
>
> So we have to tell ‘profile-generation’ what the user-visible name of
> the profile is going to be.  Attached is a very rough patch to do that.
> This is not so nice because all user interfaces will now have to pass
> that #:target parameter or etc/profile will be “wrong.”
>
> Another option would be to simply run:
>
>   eval `guix package -p ~/.guix-profile --search-paths`
>
> This has two downsides:
>
>   1. It takes ~200 ms to run on my laptop, which can maybe be
>      noticeable; OTOH it’s only for interactive shells, so maybe that’s
>      OK.
>
>   2. If there’s a manifest format change and /etc/profile calls a ‘guix’
>      command that cannot handle the manifest format (because it’s older
>      than the ‘guix’ used to build the profile), then it doesn’t work at
>      all (that’s a bit contrived, but not completely impossible.)
>
> Thoughts?
>
How about using a shell variable as input for the location:
(replace /gnu/store/xxx with $GUIX_PROFILE)

  # etc/profile
  export PATH=$GUIX_PROFILE/bin:$PATH
  export MANPATH=$GUIX_PROFILE/share/man:$MANPATH
  ...

Then when 'source' it, we pass the location:
(we did know where $GUIX_PROFILE is when do the 'source')

  # ~/.bash_profile
  GUIX_PROFILE=$HOME/.guix-profile
  if [ -f $GUIX_PROFILE/etc/profile ]; then
    . $GUIX_PROFILE/etc/profile
  fi

  # /etc/profile
  GUIX_PROFILE=/run/current-system/profile
  source $GUIX_PROFILE/etc/profile

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

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

> How about using a shell variable as input for the location:
> (replace /gnu/store/xxx with $GUIX_PROFILE)
>
>   # etc/profile
>   export PATH=$GUIX_PROFILE/bin:$PATH
>   export MANPATH=$GUIX_PROFILE/share/man:$MANPATH
>   ...
>
> Then when 'source' it, we pass the location:
> (we did know where $GUIX_PROFILE is when do the 'source')
>
>   # ~/.bash_profile
>   GUIX_PROFILE=$HOME/.guix-profile
>   if [ -f $GUIX_PROFILE/etc/profile ]; then
>     . $GUIX_PROFILE/etc/profile
>   fi
>
>   # /etc/profile
>   GUIX_PROFILE=/run/current-system/profile
>   source $GUIX_PROFILE/etc/profile

Yes, but we would also like users to be able to source
~/.guix-profile/etc/profile themselves directly, and it wouldn’t be nice
to ask them to set GUIX_PROFILE before sourcing it.

Ludo’.

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

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

> How about using a shell variable as input for the location:
> (replace /gnu/store/xxx with $GUIX_PROFILE)
>
>   # etc/profile
>   export PATH=$GUIX_PROFILE/bin:$PATH
>   export MANPATH=$GUIX_PROFILE/share/man:$MANPATH
>   ...
>
> Then when 'source' it, we pass the location:
> (we did know where $GUIX_PROFILE is when do the 'source')
>
>   # ~/.bash_profile
>   GUIX_PROFILE=$HOME/.guix-profile
>   if [ -f $GUIX_PROFILE/etc/profile ]; then
>     . $GUIX_PROFILE/etc/profile
>   fi
>
>   # /etc/profile
>   GUIX_PROFILE=/run/current-system/profile
>   source $GUIX_PROFILE/etc/profile

I ended up doing that in d664f1b.  Please check d664f1b and d995942 and
report and issues/bugs.

Part of the initial problem you reported had to do with combining
profiles (perl in one profile, perl-xml-parser in another.)  This part
is not addressed yet, and it turns out to be more common than I
initially thought: consider for instance MANPATH (with man-db installed
in the system profile and man pages in the user’s profile.)

Unfortunately the etc/profile files are not going to allow us to solve
that.  ‘guix package --search-paths’ could do the actual combination,
though.

Thanks,
Ludo’.

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

[Ludovic Courtès]

Some progress has been made: fc2d233 allows search paths for multiple
profiles to be combined.

So I think I will eventually (‘guix-devel’ needs to be updated first)
change /etc/profile to do:

  eval `guix package -p /run/current-system/profile \
          -p $HOME/.guix-profile --search-paths`

That should solve the combined profile issue.

This operation takes ~400ms on my machine.  This would be a problem if
we had to do it every time a shell is started, but here we only need to
do it for log-in shells, which is rare enough.

WDYT?

Thanks,
Ludo’.

bug#20255: (old)bug#20255: 'search-paths' should respect both user and system profiles

[zimoun]

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:

--8<---------------cut here---------------start------------->8---
+  eval `/run/current-system/profile/bin/guix package \\
+          -p /run/current-system/profile             \\
+          -p \"$HOME/.guix-profile\" --search-paths`
--8<---------------cut here---------------end--------------->8---


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.



Well, is the issue still happening 4 years later?
If yes, what should be the fix? What is the status quo?
If no, let close the bug.



Note that other patches are still pending [4] and [5] -- probably
irrelevant now.



All the best,
simon


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44
[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#8
[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#26

bug#20255: (old)bug#20255: 'search-paths' should respect both user and system profiles

[Alex Kost]

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.

-- 
Alex

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

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

[Leo Prikler]

Am Freitag, den 25.06.2021, 22:37 -0400 schrieb 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 :-).
I think there is a solution, that works not only for the case of
disabling this unwanted feature, but also to add in support for
multiple profiles, i.e. if the user has more than just their .guix-
profile to load.

If we made this feature opt-in in that a user would first have to write
their profiles to $HOME/.config/guix/default-profiles or a similarly
named file in $HOME/.config/guix, we could simply not run the command
if the file doesn't exist, and if it exists run it using the profiles
in there.

Most users will likely have
--8<---------------cut here---------------start------------->8---
/home/myself/.guix-profile
/run/current-system/profile
--8<---------------cut here---------------end--------------->8---
in it, but you could also have
--8<---------------cut here---------------start------------->8---
/home/myself/.guix-extra-profiles/emacs
/home/myself/.guix-extra-profiles/hundreds-of-npm-packages
/home/myself/.guix-extra-profiles/rusty-rust
/home/myself/.guix-profile
/run/current-system/profile
--8<---------------cut here---------------end--------------->8---

Of course, having to type out /home/myself is somewhat weird, and the
last two lines are a bit of boilerplate, that one might want to avoid. 
We could alternatively make it so that an empty file means "use
$HOME/.guix-profile and /run/current-system/profile", such that those
are always sourced no matter what.  WDYT?

Regards,
Leo

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

[Maxim Cournoyer]

Hi Leo,

[...]

> I think there is a solution, that works not only for the case of
> disabling this unwanted feature, but also to add in support for
> multiple profiles, i.e. if the user has more than just their .guix-
> profile to load.
>
> If we made this feature opt-in in that a user would first have to write
> their profiles to $HOME/.config/guix/default-profiles or a similarly
> named file in $HOME/.config/guix, we could simply not run the command
> if the file doesn't exist, and if it exists run it using the profiles
> in there.
>
> Most users will likely have
>
> /home/myself/.guix-profile
> /run/current-system/profile
>
> in it, but you could also have
>
> /home/myself/.guix-extra-profiles/emacs
> /home/myself/.guix-extra-profiles/hundreds-of-npm-packages
> /home/myself/.guix-extra-profiles/rusty-rust
> /home/myself/.guix-profile
> /run/current-system/profile
>
> Of course, having to type out /home/myself is somewhat weird, and the
> last two lines are a bit of boilerplate, that one might want to avoid. 
> We could alternatively make it so that an empty file means "use
> $HOME/.guix-profile and /run/current-system/profile", such that those
> are always sourced no matter what.  WDYT?

I like this later idea (does what a user would reasonably expect by
default, which is to consider both the system and the user profile by
default).  A user specifying that file manually could then override the
default behavior to have it source extra profiles, or none at all.

Some small difference I'd propose:

An non-existing $HOME/.config/guix/default-profiles file would be
equivalent to an existing file containing:

- $HOME/.guix-profile
- /run/current-system/profile

as the default behavior.

Now we'd need to look at how feasible it is to implement such a feature.

Thanks for this clever suggestion!  It seems we may be able to find a
good middle ground :-).

Maxim

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

[Leo Prikler]

Am Montag, den 28.06.2021, 00:35 -0400 schrieb Maxim Cournoyer:
> Hi Leo,
> 
> [...]
> 
> > I think there is a solution, that works not only for the case of
> > disabling this unwanted feature, but also to add in support for
> > multiple profiles, i.e. if the user has more than just their .guix-
> > profile to load.
> > 
> > If we made this feature opt-in in that a user would first have to
> > write
> > their profiles to $HOME/.config/guix/default-profiles or a
> > similarly
> > named file in $HOME/.config/guix, we could simply not run the
> > command
> > if the file doesn't exist, and if it exists run it using the
> > profiles
> > in there.
> > 
> > Most users will likely have
> > 
> > /home/myself/.guix-profile
> > /run/current-system/profile
> > 
> > in it, but you could also have
> > 
> > /home/myself/.guix-extra-profiles/emacs
> > /home/myself/.guix-extra-profiles/hundreds-of-npm-packages
> > /home/myself/.guix-extra-profiles/rusty-rust
> > /home/myself/.guix-profile
> > /run/current-system/profile
> > 
> > Of course, having to type out /home/myself is somewhat weird, and
> > the
> > last two lines are a bit of boilerplate, that one might want to
> > avoid. 
> > We could alternatively make it so that an empty file means "use
> > $HOME/.guix-profile and /run/current-system/profile", such that
> > those
> > are always sourced no matter what.  WDYT?
> 
> I like this later idea (does what a user would reasonably expect by
> default, which is to consider both the system and the user profile by
> default).  A user specifying that file manually could then override
> the
> default behavior to have it source extra profiles, or none at all.
> 
> Some small difference I'd propose:
> 
> An non-existing $HOME/.config/guix/default-profiles file would be
> equivalent to an existing file containing:
> 
> - $HOME/.guix-profile
> - /run/current-system/profile
> 
> as the default behavior.
The behaviour for a missing default-profiles is nothing so as to
address the concerns raised by Alex Kost about running the guix binary
without the user's consent.  It still runs external binaries such as
test, but IIRC those are already run in our existing setup, so that's
not really a concern worth raising.

I do agree, that your solution is more reasonable if there's nothing
else to consider.

> Now we'd need to look at how feasible it is to implement such a
> feature.
A naïve implementation would be a pipe with sed and xargs, but I don't
know how well that'd guard against shell code exploits.  A more
complicated approach might take a few lines of shell code, but I don't
think it would be excessively large.

> Thanks for this clever suggestion!  It seems we may be able to find a
> good middle ground :-).
> 
> Maxim

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

[Alex Kost]

Maxim Cournoyer (2021-06-25 22:37 -0400) wrote:

[...]
> 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 :-).

I can modify /etc/profile with any "normal" linux distribution but I
cannot do it with the Guix System.  And I find it awful that you think
it should stay like that.  I am for providing as much freedom for a user
(to configure their system) as possible.

The current /etc/profile is bearable for me, but if you add a "guix ..."
call there without providing a way to modify that file, I will probably
stop using the Guix System.

Or maybe there is a hacky way to change /etc/profile ?  If so, please
share a code how this can be done.  (Then I will not complain anymore)

-- 
Alex

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

[Maxim Cournoyer]

Hi Alex,

Alex Kost <alezost@gmail.com> writes:

> Maxim Cournoyer (2021-06-25 22:37 -0400) wrote:
>
> [...]
>> 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 :-).
>
> I can modify /etc/profile with any "normal" linux distribution but I
> cannot do it with the Guix System.  And I find it awful that you think
> it should stay like that.  I am for providing as much freedom for a user
> (to configure their system) as possible.
> The current /etc/profile is bearable for me, but if you add a "guix ..."
> call there without providing a way to modify that file, I will probably
> stop using the Guix System.
>
> Or maybe there is a hacky way to change /etc/profile ?  If so, please
> share a code how this can be done.  (Then I will not complain anymore)

Thanks for the reply!  I just wanted to make sure the extra energy to be
spent on the search & implementation of a better solution would not be
in vain; now I that know that it won't!

I like the idea proposed by Leo Prikler; the one about giving the
possibility to users to override the list of default profiles considered
under a file such as ~/.config/guix/default-profiles.

The default would be to load both combine the environment variables of
the system and user profiles using 'guix package --search-paths', but a
user could opt-out of that by providing an empty file, or customize the
list of profiles the way they'd like.

Would that be an acceptable solution from your point of view?

Thank you,

Maxim

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

[Alex Kost]

Maxim Cournoyer (2021-06-28 00:48 -0400) wrote:

> Alex Kost <alezost@gmail.com> writes:
[...]
>> I can modify /etc/profile with any "normal" linux distribution but I
>> cannot do it with the Guix System.  And I find it awful that you think
>> it should stay like that.  I am for providing as much freedom for a user
>> (to configure their system) as possible.
>> The current /etc/profile is bearable for me, but if you add a "guix ..."
>> call there without providing a way to modify that file, I will probably
>> stop using the Guix System.
>>
>> Or maybe there is a hacky way to change /etc/profile ?  If so, please
>> share a code how this can be done.  (Then I will not complain anymore)
>
> Thanks for the reply!  I just wanted to make sure the extra energy to be
> spent on the search & implementation of a better solution would not be
> in vain; now I that know that it won't!
>
> I like the idea proposed by Leo Prikler; the one about giving the
> possibility to users to override the list of default profiles considered
> under a file such as ~/.config/guix/default-profiles.
>
> The default would be to load both combine the environment variables of
> the system and user profiles using 'guix package --search-paths', but a
> user could opt-out of that by providing an empty file, or customize the
> list of profiles the way they'd like.
>
> Would that be an acceptable solution from your point of view?

Sure!  Any solution that I can configure for my needs is good for me,
thank you!

-- 
Alex

bug#20255: «the Oldest» [PATCH] 'search-paths' should respect both user and system profiles

[zimoun]

Hi,

The bug#20255 [#] is the oldest patch, still there even if almost is
done.  Let enjoy this patch squash day on Dec. the 18th [0] to close
it. ;-)

Below the summary I wrote couple of months ago.  And the Alex’s answer:

        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.

Let’s tackle it! :-)

0: <https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00215.html>


All the best,
simon

#: <http://issues.guix.gnu.org/issue/20255>


On Fri, 21 Feb 2020 at 16:53, zimoun <zimon.toutoune@gmail.com> wrote:

> 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.
>
> Well, is the issue still happening 4 years later?
> If yes, what should be the fix? What is the status quo?
> If no, let close the bug.
>
> Note that other patches are still pending [4] and [5] -- probably
> irrelevant now.
>
> All the best,
> simon
>
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255
> [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41
> [3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44
> [4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#8
> [5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#26

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

[宋文武 via Bug reports for GNU Guix]

Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
search-paths from multiple profiles by `guix package --search-paths`, in
~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
update).  


Close now!

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

[Maxim Cournoyer]

Hi,

宋文武 <iyzsong@envs.net> writes:

> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
> search-paths from multiple profiles by `guix package --search-paths`, in
> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
> update).  
>
>
> Close now!

Cool, thanks for the update.  Perhaps a NEWS entry would be useful to
keep Guix System existing users in the loop?  Until we have a better
mechanism/approach to these stateful files that don't change past the
original installation.

-- 
Thanks,
Maxim

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

[宋文武]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> 宋文武 <iyzsong@envs.net> writes:
>
>> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
>> search-paths from multiple profiles by `guix package --search-paths`, in
>> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
>> update).  
>>
>>
>> Close now!

Well, I reopen this since the changes is not totaly (duplicates in
/etc/profile, guix home changes) done, sorry...

>
> Cool, thanks for the update.  Perhaps a NEWS entry would be useful to
> keep Guix System existing users in the loop?  Until we have a better
> mechanism/approach to these stateful files that don't change past the
> original installation.

Now, I send more patches with NEWS entry.


Add guix-devel to CC for more reviews, TIA!

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

[Josselin Poiret via Bug reports for GNU Guix]

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

Hi,

宋文武 via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
> search-paths from multiple profiles by `guix package --search-paths`, in
> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
> update).  
>
>
> Close now!

I just checked and zsh does load /etc/profile by default on login, and
on guix system that also loads the user's profile by default.  Should we
remove this so that profiles are only loaded once?

Best,
-- 
Josselin Poiret

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

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

[Maxim Cournoyer]

Hi,

Josselin Poiret <dev@jpoiret.xyz> writes:

> Hi,
>
> 宋文武 via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>
>> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
>> search-paths from multiple profiles by `guix package --search-paths`, in
>> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
>> update).  
>>
>>
>> Close now!
>
> I just checked and zsh does load /etc/profile by default on login, and
> on guix system that also loads the user's profile by default.  Should we
> remove this so that profiles are only loaded once?

Just to make sure, remove what exactly?

-- 
Thanks,
Maxim

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

[Josselin Poiret via Bug reports for GNU Guix]

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

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Just to make sure, remove what exactly?

Remove the bit in /etc/profile that loads the user's profile, if it is
indeed supposed to be loaded by the user's own ~/.zprofile or
~/.bash_profile.  At least, I don't know if there is a general agreement
on what should be done in /etc/profile vs. the user's own config.

Best,
-- 
Josselin Poiret

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

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

[宋文武 via Bug reports for GNU Guix]

Josselin Poiret <dev@jpoiret.xyz> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Just to make sure, remove what exactly?
>
> Remove the bit in /etc/profile that loads the user's profile, if it is
> indeed supposed to be loaded by the user's own ~/.zprofile or
> ~/.bash_profile.

Remove will break existed systems, so need a NEWS entry as Maxim
mentioned, and maybe some explainations and examples in the manual about
how to setup the environments as needed.

I could make a patch for it this weekend if no one beats me..


> At least, I don't know if there is a general agreement
> on what should be done in /etc/profile vs. the user's own config.

I think hopefully we can agree that /etc/profile only handle the system
profile, and user's own config can decide what it want.

Despite mitigation, it still work out of the box with skeletons, and
user can arrange priorities among profiles, or disable the system one.
Or configure it via home-shell-profile (TODO: need some changes).

bug#20255: [PATCH 1/4] home: shells: Merge search-paths of multiple profiles.

[iyzsong--- via Bug reports for GNU Guix]

From: 宋文武 <iyzsong@member.fsf.org>

This is a followup to 40310efde9b4a4f2cf98081d6cd10f843685ebb6.

* gnu/home/services.scm (environment-variables->setup-environment-script):
Merge search-paths from multiple profiles via "guix package".
* gnu/home/services/shells.scm (zsh-file-zprofile, add-bash-configuration):
Adjust comments.
---
 gnu/home/services.scm        | 14 ++++++++++----
 gnu/home/services/shells.scm |  6 ++----
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index b17a34d19d..3a061cf310 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -260,11 +260,17 @@ (define (environment-variables->setup-environment-script vars)
                            (lambda (port)
                              (set-port-encoding! port "UTF-8")
                              (display "\
-HOME_ENVIRONMENT=$HOME/.guix-home
-GUIX_PROFILE=\"$HOME_ENVIRONMENT/profile\"
-PROFILE_FILE=\"$HOME_ENVIRONMENT/profile/etc/profile\"
-[ -f $PROFILE_FILE ] && . $PROFILE_FILE
+# Merge search-paths from multiple profiles, the order matters.
+eval \"$(guix package --search-paths \\
+-p $HOME/.config/guix/current \\
+-p $HOME/.guix-home/profile \\
+-p $HOME/.guix-profile \\
+-p /run/current-system/profile)\"
+
+# Prepend setuid programs.
+export PATH=/run/setuid-programs:$PATH
 
+HOME_ENVIRONMENT=$HOME/.guix-home
 case $XDG_DATA_DIRS in
   *$HOME_ENVIRONMENT/profile/share*) ;;
   *) export XDG_DATA_DIRS=$HOME_ENVIRONMENT/profile/share:$XDG_DATA_DIRS ;;
diff --git a/gnu/home/services/shells.scm b/gnu/home/services/shells.scm
index f05f2221d6..7c8908083e 100644
--- a/gnu/home/services/shells.scm
+++ b/gnu/home/services/shells.scm
@@ -185,9 +185,8 @@ (define (zsh-file-zprofile config)
   (mixed-text-file
    "zprofile"
    "\
-# Set up the system, user profile, and related variables.
+# Set up environment variables of profiles.
 source /etc/profile
-# Set up the home environment profile.
 source ~/.profile
 
 # It's only necessary if zsh is a login shell, otherwise profiles will
@@ -399,9 +398,8 @@ (define (add-bash-configuration config)
       ,(mixed-text-file
         "bash_profile"
         "\
-# Set up the system, user profile, and related variables.
+# Set up environment variables of profiles.
 # /etc/profile will be sourced by bash automatically
-# Set up the home environment profile.
 if [ -f ~/.profile ]; then source ~/.profile; fi
 
 # Honor per-interactive-shell startup file

base-commit: cf82526ac400fe953ddfbf9d7458d62ea4871d10
-- 
2.40.1

bug#20255: [PATCH 2/4] system: default-skeletons: Set up Guix home profile when it exists.

[iyzsong--- via Bug reports for GNU Guix]

From: 宋文武 <iyzsong@member.fsf.org>

This is a followup to 40310efde9b4a4f2cf98081d6cd10f843685ebb6.

* gnu/system/shadow.scm (default-skeletons)[bash_profile, zprofile]:
Source '~/.profile' when '~/.guix-home' exists.
---
 gnu/system/shadow.scm | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/gnu/system/shadow.scm b/gnu/system/shadow.scm
index 4a8cc87f0f..afb47fc42d 100644
--- a/gnu/system/shadow.scm
+++ b/gnu/system/shadow.scm
@@ -151,9 +151,6 @@ (define (default-skeletons)
 'useradd' in the home directory of newly created user accounts."
 
   (let ((profile (plain-file "bash_profile" "\
-# Set up Guix Home profile
-if [ -f ~/.profile ]; then . ~/.profile; fi
-
 # Honor per-interactive-shell startup file
 if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
 
@@ -165,6 +162,9 @@ (define (default-skeletons)
 
 # Prepend setuid programs.
 export PATH=/run/setuid-programs:$PATH
+
+# Set up Guix Home profile
+if [ -d ~/.guix-home ]; then . ~/.profile; fi
 "))
         (bashrc  %default-bashrc)
         (zprofile    (plain-file "zprofile" "\
@@ -179,6 +179,9 @@ (define (default-skeletons)
 
 # Prepend setuid programs.
 export PATH=/run/setuid-programs:$PATH
+
+# Set up Guix Home profile
+if [ -d ~/.guix-home ]; then . ~/.profile; fi
 "))
         (xdefaults (plain-file "Xdefaults" "\
 XTerm*utf8: always
-- 
2.40.1

bug#20255: [PATCH 3/4] system: Only source system profile's settings in '/etc/profile'.

[iyzsong--- via Bug reports for GNU Guix]

From: 宋文武 <iyzsong@member.fsf.org>

This is a followup to 40310efde9b4a4f2cf98081d6cd10f843685ebb6.

* gnu/system.scm (operating-system-etc-service)[profile]:
Don't source profile of '~/.guix-profile' and '~/.config/guix/current'.
---
 gnu/system.scm | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 354f58f55b..a48c206e18 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -1009,8 +1009,8 @@ (define* (operating-system-etc-service os)
         ;; environment variables.
         (profile    (mixed-text-file "profile"  "\
 # Crucial variables that could be missing in the profiles' 'etc/profile'
-# because they would require combining both profiles.
-# FIXME: See <http://bugs.gnu.org/20255>.
+# because they would require honoring search paths of dependencies.
+# FIXME: See <http://bugs.gnu.org/22138>.
 export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
 export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
 export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
@@ -1037,27 +1037,12 @@ (define* (operating-system-etc-service os)
   export `cat /etc/environment | cut -d= -f1`
 fi
 
-# Arrange so that ~/.config/guix/current comes first.
-for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
-do
-  if [ -f \"$profile/etc/profile\" ]
-  then
-    # Load the user profile's settings.
-    GUIX_PROFILE=\"$profile\" ; \\
-    . \"$profile/etc/profile\"
-  else
-    # At least define this one so that basic things just work
-    # when the user installs their first package.
-    export PATH=\"$profile/bin:$PATH\"
-  fi
-done
+# Make basic things just work when the user installs their first package.
+export PATH=\"$HOME/.config/guix/current/bin:$HOME/.guix-profile/bin:$PATH\"
 
 # Prepend setuid programs.
 export PATH=/run/setuid-programs:$PATH
 
-# Arrange so that ~/.config/guix/current/share/info comes first.
-export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
-
 # Set the umask, notably for users logging in via 'lsh'.
 # See <http://bugs.gnu.org/22650>.
 umask 022
-- 
2.40.1

bug#20255: [PATCH 4/4] news: Add entry for '/etc/profile' changes.

[iyzsong--- via Bug reports for GNU Guix]

From: 宋文武 <iyzsong@member.fsf.org>

* etc/news.scm: Add entry.
---
 etc/news.scm | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/etc/news.scm b/etc/news.scm
index f5dc3ca0d5..2da92eeac3 100644
--- a/etc/news.scm
+++ b/etc/news.scm
@@ -26,6 +26,39 @@
 (channel-news
  (version 0)
 
+ (entry (commit "2e888b4d07c67ad74fbb4ec9afb812a236852027")
+        (title
+         (en "@file{/etc/profile} changes require manual intervention"))
+        (body
+         (en "On Guix System, now the personal shell startup file
+@file{~/.bash_profile} or @file{~/.zprofile} will be used to set up
+environment variables for the user instead of @file{/etc/profile}.  And
+search-paths from multiple profiles are honored, which means a system
+configured Xfce desktop environment can find its panel plugins in the user
+profile.
+
+Before run @command{guix system reconfigure}, append the snippet below to each
+user's @file{~/.bash_profile} or @file{~/.zprofile}:
+
+@example
+# Merge search-paths from multiple profiles, the order matters.
+eval \"$(guix package --search-paths \\
+-p $HOME/.config/guix/current \\
+-p $HOME/.guix-profile \\
+-p /run/current-system/profile)\"
+
+# Prepend setuid programs.
+export PATH=/run/setuid-programs:$PATH
+
+# Set up Guix Home profile
+if [ -d ~/.guix-home ]; then . ~/.profile; fi
+@end example
+
+Or you can override them with updated skeleton files after system reconfigure.
+In addition, Guix Home users need to upgrade via @command{guix home
+reconfigure}.  See @uref{https://issues.guix.gnu.org/20255} for the
+rationale.")))
+
  (entry (commit "ae11fcb84ac478dfa56d322ef08890645183a087")
         (title
          (en "New @option{--with-configure-flag} transformation option")
-- 
2.40.1