From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Kost Subject: Re: Adding operating-system field for a custom /etc/profile. Date: Tue, 24 Nov 2015 22:36:47 +0300 Message-ID: <871tbfrxyo.fsf@gmail.com> References: <877ftschjt.fsf@gmail.com> <87fv8fip01.fsf@gnu.org> <87d23j1bxk.fsf@gmail.com> <871tjyfnl8.fsf@gnu.org> <876199q4z1.fsf@gmail.com> <87ioca4ojo.fsf@gnu.org> <87lh9tvcws.fsf@gnu.org> <87h9kguwc4.fsf@gmail.com> <87ziy7d90z.fsf@gnu.org> <874mgfkxee.fsf@gmail.com> <87wptb5d1y.fsf@gnu.org> <87r3jisc76.fsf@gmail.com> <87lh9q1f2i.fsf@gnu.org> <877fl9q3gv.fsf@gmail.com> <87h9kdy6ty.fsf@gnu.org> <871tbh53rt.fsf@gmail.com> <87vb8sss7j.fsf@gnu.org> <87y4doscmg.fsf_-_@gmail.com> <87wpt7d0ls.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1JOX-0006xi-Qt for guix-devel@gnu.org; Tue, 24 Nov 2015 14:36:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1JOU-0005UV-Js for guix-devel@gnu.org; Tue, 24 Nov 2015 14:36:53 -0500 In-Reply-To: <87wpt7d0ls.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 24 Nov 2015 13:48:47 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Ludovic Court=C3=A8s (2015-11-24 15:48 +0300) wrote: > Alex Kost skribis: > >> Ludovic Court=C3=A8s (2015-11-23 17:31 +0300) wrote: > > [...] > >>>> Great! So is it OK to send a patch for adding =E2=80=98profile-file= =E2=80=99 field? >>> >>> Hmm, I=E2=80=99m not sure if we want to give direct access to /etc/prof= ile 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 =E2=80=98operating-system=E2=80= =99 declaration, >>> such as: >>> >>> >>> export LANG=3D"en_US.utf8" >>> export TZ=3D"Europe/Paris" >>> export >>> TZDIR=3D"/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share= /zoneinfo" >>> >>> # Tell 'modprobe' & co. where to look for modules. >>> export LINUX_MODULE_DIRECTORY=3D/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 =E2=80=98profile-file=E2=80=99 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: =C2=ABWe will not provide "rm" command, because a newcomer may >> accidentally run "rm -rf ~"=C2=BB. Please give me an opportunity to sho= ot >> 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: =E2=80=9CI specified the en_US.utf8 lo= cale in > the declaration, but somehow I end up with the C locale=E2=80=9D; =E2=80= =9Cwhy doesn=E2=80=99t > modprobe find modules?=E2=80=9D; =E2=80=9CI=E2=80=99m stuck in the GMT ti= mezone=E2=80=9D, 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 =E2=80=98profile-file=E2=80= =99 field, > without noticing that this would wipe out all the rest of the useful > stuff from there. Sorry again, but I read: =C2=ABNo, no, we really shouldn't provide "rm" command, because it can do a big harm!=C2=BB 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.n= ix > > There=E2=80=99s a bunch of high-level options like =E2=80=98shellAliases= =E2=80=99, =E2=80=98promptInit=E2=80=99, > 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. > > =E2=80=98shellInit=E2=80=99 in that file refers to =E2=80=98setEnvironmen= t=E2=80=99, as defined here: > > https://github.com/NixOS/nixos/blob/master/modules/programs/environment= .nix > https://github.com/NixOS/nixos/blob/master/modules/config/shells-enviro= nment.nix > > Interestingly, that part does like =E2=80=98guix package --search-paths= =E2=80=99 as > suggested at , > but does it in Bash and without stat=E2=80=99ing files. Thanks for this NixOS info! > Anyway, I think the way forward is to make /etc/profile modular in > similar fashion. What about starting with an /etc/profile service that > can receive Bash snippets and paste them in the middle of the file, > right before: > > if [ -n "$BASH_VERSION" -a -f /etc/bashrc ] > then > # Load Bash-specific initialization code. > . /etc/bashrc > fi > > Does that make sense? I agree that a modular /etc/profile would be great, but only if *any* part of it can be changed or removed, otherwise this decision will have the same problem: one day there will appear users who would like to change the parts that cannot be changed. But still I prefer to have a straightforward way to set my own /etc/profile. Or maybe it would be good to have even a more general solution: a way to specify any file that goes to "/etc" dir, something like this: (operating-system ;; ... (etc-files ("hosts" (local-file "/home/me/guix/etc/hosts")) ("profile" (local-file "/home/me/guix/bash/my-favourite-etc-profile")) ("fstab" (local-file "/home/me/guix/etc/fstab")))) You will probably consider this decision evil, but for me it's a perfect solution. As I see it: - these 'etc-files' should have a priority over the default generated /etc files; - "guix system" command should report if these files override the default ones, and it can even create "/etc/foobar.default" so that a user could look at it any time; - and of course the manual should warn that 'etc-files' is a very dangerous option, blah, blah, blah. The most valuable thing for me is customizability, and I just can't stand the situation when developers refuse to provide a way to customize defaults for no reason (or just because it is potentially dangerous). I don't like the default grub.cfg, but I've never complained about it because there is "--no-grub" option, so I can install grub on my own and use my own grub config. This is great! :-) The problem with /etc files, is that they can't be edited directly, and operating-system doesn't provide a way to change any aspect of these files, so I always find things that I don't like and that can't be changed. This is bad! :-( > I can give it a try if you want. Sorry, but this is not what I want. I would like to have a full control on any aspect of my system. --=20 Alex