Alex Kost <alez...@gmail.com> skribis: > Ludovic Courtès (2015-11-23 17:31 +0300) wrote:
[...] >>> Great! So is it OK to send a patch for adding ‘profile-file’ field? >> >> Hmm, I’m not sure if we want to give direct access to /etc/profile like >> this. > > Oh, no! If there is one person (me) who wants to have a full control on > his /etc/profile, there may be the others with the same wish. > >> The problem is that several things in there are here to make the system >> work, and to to make it conform to the ‘operating-system’ declaration, >> such as: >> >> >> export LANG="en_US.utf8" >> export TZ="Europe/Paris" >> export >> TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo" >> >> # Tell 'modprobe' & co. where to look for modules. >> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules > > Yes, that's why I suggest to add a note to the manual about a danger of > using this field. > >> The risk I see with adding a raw ‘profile-file’ option is that newcomers >> may end up getting rid of such things without really noticing, and then >> getting a broken system. > > But a newcomer will learn about this option only if (s)he reads the > manual with the warning I've mentioned. For me, your phrase sounds > like: «We will not provide "rm" command, because a newcomer may > accidentally run "rm -rf ~"». Please give me an opportunity to shoot > myself in the foot! > > Besides will the system really be broken? Yes. > What do you mean? I can already see the bug reports: “I specified the en_US.utf8 locale in the declaration, but somehow I end up with the C locale”; “why doesn’t modprobe find modules?”; “I’m stuck in the GMT timezone”, etc. etc. And only after 5 messages will we learn that the user wanted to add *one* line to /etc/profile, did that via the ‘profile-file’ field, without noticing that this would wipe out all the rest of the useful stuff from there. > Even if /etc/profile is empty, the system will boot successfully and a > user could login, no? Sure, but merely booting is not sufficient. >> What about instead giving a way to populate the top and/or bottom of >> this file? Controversial parts, if any, could still be turned on and >> off by adding or removing services that add these lines? > > It is better than nothing, but it is not sufficient IMO. Any part of > /etc/profile can be controversial (you'll never know what a user would > like to change), so I think providing an option to change this file > completely is essential. > > But I agree that appending/prepending some lines may also be useful for > those who like to keep the default /etc/profile and who just want to add > something to it. OK. NixOS apparently takes in approach similar to that: https://github.com/NixOS/nixos/blob/master/modules/programs/bash/bash.nix There’s a bunch of high-level options like ‘shellAliases’, ‘promptInit’, etc. that get pasted in /etc/profile or /etc/bashrc. In addition, /etc/profile sources /etc/profile.local if available, and similarly for /etc/bashrc. ‘shellInit’ in that file refers to ‘setEnvironment’, as defined here: https://github.com/NixOS/nixos/blob/master/modules/programs/environment.nix https://github.com/NixOS/nixos/blob/master/modules/config/shells-environment.nix Interestingly, that part does like ‘guix package --search-paths’ as suggested at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41>, but does it in Bash and without stat’ing files. Anyway, I think the way forward is to make /etc/profile modular in similar fashion. What about starting with an /etc/profile service that can receive Bash snippets and paste them in the middle of the file, right before: if [ -n "$BASH_VERSION" -a -f /etc/bashrc ] then # Load Bash-specific initialization code. . /etc/bashrc fi Does that make sense? I can give it a try if you want. Thanks, Ludo’.
