[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Customizing /etc
From: |
Alex Kost |
Subject: |
Re: Customizing /etc |
Date: |
Mon, 30 Nov 2015 12:11:53 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Ludovic Courtès (2015-11-27 17:58 +0300) wrote:
> Alex Kost <address@hidden> 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
Re: Adding operating-system field for a custom /etc/profile., 宋文武, 2015/11/24
/etc/environment and /etc/profile, Ludovic Courtès, 2015/11/27