Customizing /etc

Customizing /etc

[Alex Kost]

This is almost the same message as:

  http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html

I mean this is a reminder on the subject.

Ludovic, I think you suggested a good solution to a "Customizing
/etc/profile" problem.  Since I will no longer be a blocker of
<http://bugs.gnu.org/20255> after this fix, would you like to commit
that change, or are there any issues with that?

-- 
Thanks,
Alex

Re: Customizing /etc

[Ludovic Courtès]

Hi Alex,

Alex Kost <alezost@gmail.com> skribis:

> This is almost the same message as:
>
>   http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html
>
> I mean this is a reminder on the subject.

Yes, I haven’t forgotten about it, contrary to what one might think.
;-)

> Ludovic, I think you suggested a good solution to a "Customizing
> /etc/profile" problem.  Since I will no longer be a blocker of
> <http://bugs.gnu.org/20255> after this fix, would you like to commit
> that change, or are there any issues with that?

In the message you cite above, I proposed to hack etc-service-type in
the same way we did for PAM.

But then I think we’d better have the generic solution in place (where
any service could be extended “at the end”, i.e., after it’s ‘compose’
and ‘extend’ procedures have been called) before people start relying on
the hack.  I even started working on it long ago, and then moved on to
something else.

I’m sorry that this has not happened yet.  I hope to resume work on it
after the release, but if someone wants to give it a shot, I will
definitely not block it.

Thanks,
Ludo’.

Re: Customizing /etc

[Alex Kost]

Ludovic Courtès (2017-05-17 10:28 +0200) wrote:

> Hi Alex,
>
> Alex Kost <alezost@gmail.com> skribis:
>
>> This is almost the same message as:
>>
>>   http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html
>>
>> I mean this is a reminder on the subject.
>
> Yes, I haven’t forgotten about it, contrary to what one might think.
> ;-)

Oh, great!  (you're right, that's what I thought :-))

>> Ludovic, I think you suggested a good solution to a "Customizing
>> /etc/profile" problem.  Since I will no longer be a blocker of
>> <http://bugs.gnu.org/20255> after this fix, would you like to commit
>> that change, or are there any issues with that?
>
> In the message you cite above, I proposed to hack etc-service-type in
> the same way we did for PAM.
>
> But then I think we’d better have the generic solution in place (where
> any service could be extended “at the end”, i.e., after it’s ‘compose’
> and ‘extend’ procedures have been called) before people start relying on
> the hack.  I even started working on it long ago, and then moved on to
> something else.

Wow, a general solution for any service sounds really great!

> I’m sorry that this has not happened yet.  I hope to resume work on it
> after the release, but if someone wants to give it a shot, I will
> definitely not block it.

I see :-)  No hurry, I just was a bit concerned that your solution was
lost, but now I know that it's not, thanks!

-- 
Alex

User-profile search paths should include system-profile directories

[Carlos Sánchez de La Lama]

Hi guys,

I have an interesting case here. I have guile installed in my system
profile, so that

/var/guix/profiles/system/profile/share/aclocal/guile.m4

is there. However, autoconf is installed in my *user* profile, so
ACLOCAL_PATH is augmented in ~/.guix-profile/etc/profile to include

~/.guix-profile/share/aclocal

But not the system-profile aclocal directory, which would be put into
ACLOCAL_PATH by /var/guix/profiles/system/profile/etc/profile if
autoconf was installed in the systme profile as well.

Is this the intended behaviour? I am wondering whether packages with
search paths should include both the user-profile directories and the
system-profile ones.

Thoughts?

BR

Carlos

-- 
'There is prodigious strength,' I answered him, 'in sorrow and despair.' 

Charles Dickens, "A Tale of Two Cities" (1859)

Re: User-profile search paths should include system-profile directories

[Ludovic Courtès]

Hello,

csanchezdll@gmail.com (Carlos Sánchez de La Lama) skribis:

> I have an interesting case here. I have guile installed in my system
> profile, so that
>
> /var/guix/profiles/system/profile/share/aclocal/guile.m4
>
> is there. However, autoconf is installed in my *user* profile, so
> ACLOCAL_PATH is augmented in ~/.guix-profile/etc/profile to include
>
> ~/.guix-profile/share/aclocal
>
> But not the system-profile aclocal directory, which would be put into
> ACLOCAL_PATH by /var/guix/profiles/system/profile/etc/profile if
> autoconf was installed in the systme profile as well.
>
> Is this the intended behaviour? I am wondering whether packages with
> search paths should include both the user-profile directories and the
> system-profile ones.

I think you’re right.  This was discussed at
<http://bugs.gnu.org/20255>, leading to a patch (for GuixSD).

However, we failed to build consensus around the approach of this patch,
so we did not apply it.  If you have ideas, please email
20255@debbugs.gnu.org.  :-)

One of the fruits of this discussion, though, is that you can do:

  guix package -p /run/current-system/profile -p ~/.guix-profile --search-paths

to get the combined search paths.

Ludo’.

Re: User-profile search paths should include system-profile directories

[Alex Kost]

Ludovic Courtès (2016-09-14 16:58 +0200) wrote:

> Hello,
>
> csanchezdll@gmail.com (Carlos Sánchez de La Lama) skribis:
>
>> I have an interesting case here. I have guile installed in my system
>> profile, so that
>>
>> /var/guix/profiles/system/profile/share/aclocal/guile.m4
>>
>> is there. However, autoconf is installed in my *user* profile, so
>> ACLOCAL_PATH is augmented in ~/.guix-profile/etc/profile to include
>>
>> ~/.guix-profile/share/aclocal
>>
>> But not the system-profile aclocal directory, which would be put into
>> ACLOCAL_PATH by /var/guix/profiles/system/profile/etc/profile if
>> autoconf was installed in the systme profile as well.
>>
>> Is this the intended behaviour? I am wondering whether packages with
>> search paths should include both the user-profile directories and the
>> system-profile ones.
>
> I think you’re right.  This was discussed at
> <http://bugs.gnu.org/20255>, leading to a patch (for GuixSD).
>
> However, we failed to build consensus around the approach of this patch,
> so we did not apply it.  If you have ideas, please email
> 20255@debbugs.gnu.org.  :-)

I think I was the one who prevents the consensus.  To make it clear, I'm
for the suggested solution, but only *after* giving a user a freedom to
avoid loading such a heavy command as "guix package --search-paths".  On
a "usual" GNU/Linux distro a user can edit /etc/profile, but on GuixSD
it is not possible currently.  That's why I think there should be
provided a possibility to override /etc/profile at first.

> One of the fruits of this discussion, though, is that you can do:
>
>   guix package -p /run/current-system/profile -p ~/.guix-profile --search-paths
>
> to get the combined search paths.

This is what I do to combine my profiles (I don't use ~/.guix-profile
but several other profiles instead).

-- 
Alex

Customizing /etc

[Ludovic Courtès]

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

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2016-09-14 16:58 +0200) wrote:
>
>> Hello,
>>
>> csanchezdll@gmail.com (Carlos Sánchez de La Lama) skribis:
>>
>>> I have an interesting case here. I have guile installed in my system
>>> profile, so that
>>>
>>> /var/guix/profiles/system/profile/share/aclocal/guile.m4
>>>
>>> is there. However, autoconf is installed in my *user* profile, so
>>> ACLOCAL_PATH is augmented in ~/.guix-profile/etc/profile to include
>>>
>>> ~/.guix-profile/share/aclocal
>>>
>>> But not the system-profile aclocal directory, which would be put into
>>> ACLOCAL_PATH by /var/guix/profiles/system/profile/etc/profile if
>>> autoconf was installed in the systme profile as well.
>>>
>>> Is this the intended behaviour? I am wondering whether packages with
>>> search paths should include both the user-profile directories and the
>>> system-profile ones.
>>
>> I think you’re right.  This was discussed at
>> <http://bugs.gnu.org/20255>, leading to a patch (for GuixSD).
>>
>> However, we failed to build consensus around the approach of this patch,
>> so we did not apply it.  If you have ideas, please email
>> 20255@debbugs.gnu.org.  :-)
>
> I think I was the one who prevents the consensus.  To make it clear, I'm
> for the suggested solution, but only *after* giving a user a freedom to
> avoid loading such a heavy command as "guix package --search-paths".  On
> a "usual" GNU/Linux distro a user can edit /etc/profile, but on GuixSD
> it is not possible currently.  That's why I think there should be
> provided a possibility to override /etc/profile at first.

Indeed, thanks for the reminder!

In fact, we have this through ‘etc-service-type’, except that currently
/etc/profile is systematically added.

So an idea that comes to mind is to allow ‘etc-service-type’ to be
extended with procedures that would be able to filter or otherwise
change the /etc entries (similar to what we do for PAM):


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

diff --git a/gnu/services.scm b/gnu/services.scm
index 7e322c5..9397232 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -426,9 +426,13 @@ directory."
                 (extensions
                  (list
                   (service-extension activation-service-type
-                                     (lambda (files)
-                                       (let ((etc
-                                              (files->etc-directory files)))
+                                     (lambda (files+procs)
+                                       (let* ((proc (apply compose
+                                                           (filter procedure?
+                                                                   files+procs)))
+                                              (files (filter pair? files+procs))
+                                              (etc
+                                               (files->etc-directory (proc files))))
                                          #~(activate-etc #$etc))))
                   (service-extension system-service-type etc-entry)))
                 (compose concatenate)

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


In your config, you could have something like:

  (services (cons (simple-service 'rm-/etc/profile etc-service-type
                                  (const (lambda (files)
                                           (assoc-delete "profile" files))))
                  %base-services))

WDYT?

In fact I think we would need to have a more generic mechanism to hook
into ‘fold-services’, but I’m not sure what it should look like.

Ludo’.

Re: Customizing /etc

[Alex Kost]

Ludovic Courtès (2016-09-19 23:08 +0900) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-09-14 16:58 +0200) wrote:
[...]
>>> However, we failed to build consensus around the approach of this patch,
>>> so we did not apply it.  If you have ideas, please email
>>> 20255@debbugs.gnu.org.  :-)
>>
>> I think I was the one who prevents the consensus.  To make it clear, I'm
>> for the suggested solution, but only *after* giving a user a freedom to
>> avoid loading such a heavy command as "guix package --search-paths".  On
>> a "usual" GNU/Linux distro a user can edit /etc/profile, but on GuixSD
>> it is not possible currently.  That's why I think there should be
>> provided a possibility to override /etc/profile at first.
>
> Indeed, thanks for the reminder!
>
> In fact, we have this through ‘etc-service-type’, except that currently
> /etc/profile is systematically added.
>
> So an idea that comes to mind is to allow ‘etc-service-type’ to be
> extended with procedures that would be able to filter or otherwise
> change the /etc entries (similar to what we do for PAM):
>
> diff --git a/gnu/services.scm b/gnu/services.scm
> index 7e322c5..9397232 100644
> --- a/gnu/services.scm
> +++ b/gnu/services.scm
> @@ -426,9 +426,13 @@ directory."
>                  (extensions
>                   (list
>                    (service-extension activation-service-type
> -                                     (lambda (files)
> -                                       (let ((etc
> -                                              (files->etc-directory files)))
> +                                     (lambda (files+procs)
> +                                       (let* ((proc (apply compose
> +                                                           (filter procedure?
> +                                                                   files+procs)))
> +                                              (files (filter pair? files+procs))
> +                                              (etc
> +                                               (files->etc-directory (proc files))))
>                                           #~(activate-etc #$etc))))
>                    (service-extension system-service-type etc-entry)))
>                  (compose concatenate)
>
>
> In your config, you could have something like:
>
>   (services (cons (simple-service 'rm-/etc/profile etc-service-type
>                                   (const (lambda (files)
>                                            (assoc-delete "profile" files))))
>                   %base-services))
>
> WDYT?

I think it would be great!  I didn't realize it can be implemented this
way.

> In fact I think we would need to have a more generic mechanism to hook
> into ‘fold-services’, but I’m not sure what it should look like.

Yeah, a more generic way would be better of course, but I think this
mixing of files and procedures is already good enough for now, as it
provides a freedom in customizing a system that we didn't have before.
Besides I will no longer object against the "search-paths" fix for the
bug 20255 :-)

-- 
Alex

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.

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

[宋文武]

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