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

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-11-24 23:30 +0300) wrote:
>
>> Alex Kost  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  objects
essentially get compiled down to a list of ; some of them are
added as a function of what the  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/, 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.

[Alex Kost]

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

> Alex Kost  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/, 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/ 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  skribis:

> Ludovic Courtès (2015-11-24 15:48 +0300) wrote:
>
>> Alex Kost  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]

宋文武 (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:
>> .
>>
>> 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

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

[Alex Kost]

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

> Alex Kost  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 ,
> 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-fi

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

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


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


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



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 

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

[Ludovic Courtès]

Alex Kost  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 ,
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’.