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 <address@hidden> skribis:
> >
> > > Ludovic Courtès (2015-11-23 02:04 +0300) wrote:
> > >
> > > > Alex Kost <address@hidden> 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?