bug#20720: Inconsistency in text fields for 'operating-system'

bug#20720: Inconsistency in text fields for 'operating-system'

[Alex Kost]

Hello, this is not a bug report, but a feature request.

I see some inconsistency in specifying text / text files in an
operating-system declaration:

- ‘sudoers’ and ‘issue’ want plain strings;

- ‘hosts-file’ and ‘mingetty-service’ (#:motd argument) want a
  'text-file' monadic procedure;

- some other services (‘syslog-service’, ‘lirc-service’, ...) want file
  names (of the configuration files).

As for me, I prefer the latter variant.  But I think the best would be
to add support for any of the above possibilities for all services or
operating-system fields.

-- 
Alex

bug#20720: Inconsistency in text fields for 'operating-system'

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> I see some inconsistency in specifying text / text files in an
> operating-system declaration:

Yeah, I agree it is somewhat annoying that there’s no single way to
handle this.  But...

> - ‘sudoers’ and ‘issue’ want plain strings;
>
> - ‘hosts-file’ and ‘mingetty-service’ (#:motd argument) want a
>   'text-file' monadic procedure;
>
> - some other services (‘syslog-service’, ‘lirc-service’, ...) want file
>   names (of the configuration files).

In reality they take a “file”, not a file name.  A file is an object
that within a gexp expands to a file name.  So it can be a ‘local-file’
object, a derivation, etc.

> As for me, I prefer the latter variant.  But I think the best would be
> to add support for any of the above possibilities for all services or
> operating-system fields.

An important criterion is whether the file needs to contain references
to store items or not.  For ‘sudoers’ and ‘issue’, that’s normally not
the case, and these are usually small files or computable files, so I
think it’s fine to use strings here (more convenient than files.)

Using monadic values as for ‘hosts-file’ and #:motd is not nice.  These
should be changed to use either a string or a file.

The best would be to always use a file-like object.  I’ve just added
‘plain-file’ for that reason.  Now I would change #:motd and
‘hosts-file’ to take a file-like object rather than a monadic value.

WDYT?


This brings up the question of how far we should go on the declarative
side: Similar to ‘local-file’ and ‘plain-file’, should we add more
declarative types, say for ‘gexp->derivation’?

My current inclination would be to not add anything beyond ‘local-file’
and ‘plain-file’: These two are useful in OS configurations, so that’s
fine, but for more elaborate things people should just use the
procedural interface.  Thoughts?

Thanks,
Ludo’.

bug#20720: Inconsistency in text fields for 'operating-system'

[Alex Kost]

Ludovic Courtès (2015-06-03 12:52 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> I see some inconsistency in specifying text / text files in an
>> operating-system declaration:
>
> Yeah, I agree it is somewhat annoying that there’s no single way to
> handle this.  But...
>
>> - ‘sudoers’ and ‘issue’ want plain strings;
>>
>> - ‘hosts-file’ and ‘mingetty-service’ (#:motd argument) want a
>>   'text-file' monadic procedure;
>>
>> - some other services (‘syslog-service’, ‘lirc-service’, ...) want file
>>   names (of the configuration files).
>
> In reality they take a “file”, not a file name.  A file is an object
> that within a gexp expands to a file name.  So it can be a ‘local-file’
> object, a derivation, etc.

Ah, thanks!  I didn't realize that ‘local-file’ or a derivation may be
used there.

>> As for me, I prefer the latter variant.  But I think the best would
>> be to add support for any of the above possibilities for all services
>> or operating-system fields.
>
> An important criterion is whether the file needs to contain references
> to store items or not.  For ‘sudoers’ and ‘issue’, that’s normally not
> the case, and these are usually small files or computable files, so I
> think it’s fine to use strings here (more convenient than files.)

Well, I don't agree about ‘sudoers’.  It may be a really big file.  Mine
is not so big, but it is 40 lines long (including some useful comments),
so I have to use some additional guile code to convert the contents of
the file into string.

> Using monadic values as for ‘hosts-file’ and #:motd is not nice.  These
> should be changed to use either a string or a file.
>
> The best would be to always use a file-like object.  I’ve just added
> ‘plain-file’ for that reason.  Now I would change #:motd and
> ‘hosts-file’ to take a file-like object rather than a monadic value.
>
> WDYT?

I beg a pardon, but if I inderstand it correctly (probably not), I don't
see a difference from the user point of view.  Previously it was:

  (hosts-file (text-file "hosts" "..."))

and now it would be:

  (hosts-file (plain-file "hosts" "..."))

> This brings up the question of how far we should go on the declarative
> side: Similar to ‘local-file’ and ‘plain-file’, should we add more
> declarative types, say for ‘gexp->derivation’?
>
> My current inclination would be to not add anything beyond ‘local-file’
> and ‘plain-file’: These two are useful in OS configurations, so that’s
> fine, but for more elaborate things people should just use the
> procedural interface.  Thoughts?

I think I'm not competent as I have a vague understanding of all this
stuff and of user's needs (except mine ☺).  What I would like to have,
is a possibility to specify my configuration files for various services
and operating-system fields.  I don't want to write text configs in my
os-config.scm file (as it happens now with ‘hosts-file’).

I'm very happy with the current behaviour of ‘syslog-service’,
‘lirc-service’ and ‘console-keymap-service’ where I just specify file
names, e.g.:

  (syslog-service #:config-file "/home/me/my-favourite-syslog.conf")

and I like this ↑ way of specifying configurations very much!  That's
what I would like to see in ‘sudoers’ and ‘hosts-file’ fields.

-- 
Thanks,
Alex

bug#20720: Inconsistency in text fields for 'operating-system'

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-06-03 12:52 +0300) wrote:

[...]

>> An important criterion is whether the file needs to contain references
>> to store items or not.  For ‘sudoers’ and ‘issue’, that’s normally not
>> the case, and these are usually small files or computable files, so I
>> think it’s fine to use strings here (more convenient than files.)
>
> Well, I don't agree about ‘sudoers’.  It may be a really big file.  Mine
> is not so big, but it is 40 lines long (including some useful comments),
> so I have to use some additional guile code to convert the contents of
> the file into string.

Ah, good point.  So let’s turn ‘sudoers’ into a file-like object.

>> Using monadic values as for ‘hosts-file’ and #:motd is not nice.  These
>> should be changed to use either a string or a file.
>>
>> The best would be to always use a file-like object.  I’ve just added
>> ‘plain-file’ for that reason.  Now I would change #:motd and
>> ‘hosts-file’ to take a file-like object rather than a monadic value.
>>
>> WDYT?
>
> I beg a pardon, but if I inderstand it correctly (probably not), I don't
> see a difference from the user point of view.  Previously it was:
>
>   (hosts-file (text-file "hosts" "..."))
>
> and now it would be:
>
>   (hosts-file (plain-file "hosts" "..."))

Right.  But it could also be:

  (hosts-file (local-file "/home/foo/my-hosts-file.txt"))

This form is pleasant when the file can be long or when it has special
syntax and you’d rather use the editor’s syntax highlighting.

> I think I'm not competent as I have a vague understanding of all this
> stuff and of user's needs (except mine ☺).  What I would like to have,
> is a possibility to specify my configuration files for various services
> and operating-system fields.  I don't want to write text configs in my
> os-config.scm file (as it happens now with ‘hosts-file’).

OK.  So that’s definitely in favor of using file-like objects pretty
much everywhere.

> I'm very happy with the current behaviour of ‘syslog-service’,
> ‘lirc-service’ and ‘console-keymap-service’ where I just specify file
> names, e.g.:
>
>   (syslog-service #:config-file "/home/me/my-favourite-syslog.conf")
>
> and I like this ↑ way of specifying configurations very much!  That's
> what I would like to see in ‘sudoers’ and ‘hosts-file’ fields.

OK.  Note that this form (directly using a local file name) works
somewhat by chance and should not be used because it defeats
reproducibility.  That is, your OS configuration actually depends on
that file in /home, which may be modified or deleted anytime, thereby
changing the syslogd behavior in unpredicable ways.

The right thing to do is:

  (syslog-service #:config-file
                  (local-file "/home/me/my-favourite-syslog.conf"))

This means that the config file is automatically added to the store and
made part of the closure of the OS config.  Now if
"/home/me/my-favourite-syslog.conf" is removed/modified, the OS behavior
remains unchanged.

I’ll prepare a patch for that and report back.

Thank you!

Ludo’.

bug#20720: Inconsistency in text fields for 'operating-system'

[Alex Kost]

Ludovic Courtès (2015-06-05 15:30 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-06-03 12:52 +0300) wrote:
>
> [...]
>
>>> An important criterion is whether the file needs to contain references
>>> to store items or not.  For ‘sudoers’ and ‘issue’, that’s normally not
>>> the case, and these are usually small files or computable files, so I
>>> think it’s fine to use strings here (more convenient than files.)
>>
>> Well, I don't agree about ‘sudoers’.  It may be a really big file.  Mine
>> is not so big, but it is 40 lines long (including some useful comments),
>> so I have to use some additional guile code to convert the contents of
>> the file into string.
>
> Ah, good point.  So let’s turn ‘sudoers’ into a file-like object.

Thanks!

>>> Using monadic values as for ‘hosts-file’ and #:motd is not nice.  These
>>> should be changed to use either a string or a file.
>>>
>>> The best would be to always use a file-like object.  I’ve just added
>>> ‘plain-file’ for that reason.  Now I would change #:motd and
>>> ‘hosts-file’ to take a file-like object rather than a monadic value.
>>>
>>> WDYT?
>>
>> I beg a pardon, but if I inderstand it correctly (probably not), I don't
>> see a difference from the user point of view.  Previously it was:
>>
>>   (hosts-file (text-file "hosts" "..."))
>>
>> and now it would be:
>>
>>   (hosts-file (plain-file "hosts" "..."))
>
> Right.  But it could also be:
>
>   (hosts-file (local-file "/home/foo/my-hosts-file.txt"))
>
> This form is pleasant when the file can be long or when it has special
> syntax and you’d rather use the editor’s syntax highlighting.

Ah, This is great! Thank you.

>> I think I'm not competent as I have a vague understanding of all this
>> stuff and of user's needs (except mine ☺).  What I would like to have,
>> is a possibility to specify my configuration files for various services
>> and operating-system fields.  I don't want to write text configs in my
>> os-config.scm file (as it happens now with ‘hosts-file’).
>
> OK.  So that’s definitely in favor of using file-like objects pretty
> much everywhere.

Yes :-)

>> I'm very happy with the current behaviour of ‘syslog-service’,
>> ‘lirc-service’ and ‘console-keymap-service’ where I just specify file
>> names, e.g.:
>>
>>   (syslog-service #:config-file "/home/me/my-favourite-syslog.conf")
>>
>> and I like this ↑ way of specifying configurations very much!  That's
>> what I would like to see in ‘sudoers’ and ‘hosts-file’ fields.
>
> OK.  Note that this form (directly using a local file name) works
> somewhat by chance and should not be used because it defeats
> reproducibility.  That is, your OS configuration actually depends on
> that file in /home, which may be modified or deleted anytime, thereby
> changing the syslogd behavior in unpredicable ways.

Yes, that's exactly what I want!  I realize the benefits of the
reproducibility but often I just want my system to depend on
/home/... files that can be modified anytime.

> The right thing to do is:
>
>   (syslog-service #:config-file
>                   (local-file "/home/me/my-favourite-syslog.conf"))
>
> This means that the config file is automatically added to the store and
> made part of the closure of the OS config.  Now if
> "/home/me/my-favourite-syslog.conf" is removed/modified, the OS behavior
> remains unchanged.

And that's exactly what I don't want!  I don't want my config files to
be put into the store.  Because I have to reconfigure the system to see
the changes.  With my current unpredicable way, I can change my
syslog.conf and the next time I boot into the same system, I will face
the changes I made.

I realize that it sounds like a strange whim and is not what is supposed
to be done, but, well, I just like it :-)

> I’ll prepare a patch for that and report back.

Thank you, in spite of all I said earlier, I really like ‘local-file’!

-- 
Alex

bug#20720: Inconsistency in text fields for 'operating-system'

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-06-05 15:30 +0300) wrote:

[...]

>> The right thing to do is:
>>
>>   (syslog-service #:config-file
>>                   (local-file "/home/me/my-favourite-syslog.conf"))
>>
>> This means that the config file is automatically added to the store and
>> made part of the closure of the OS config.  Now if
>> "/home/me/my-favourite-syslog.conf" is removed/modified, the OS behavior
>> remains unchanged.
>
> And that's exactly what I don't want!  I don't want my config files to
> be put into the store.  Because I have to reconfigure the system to see
> the changes.  With my current unpredicable way, I can change my
> syslog.conf and the next time I boot into the same system, I will face
> the changes I made.
>
> I realize that it sounds like a strange whim and is not what is supposed
> to be done, but, well, I just like it :-)

Fair enough.  :-)

Well, that will keep working, because we can’t really enforce config
files in the store.

Now, of course the solution will be for ‘guix system reconfigure’ to
restart services that can be restarted.  The goal is not to force people
to reboot for changes to take effect. :-)  That “just” has to be done.

>> I’ll prepare a patch for that and report back.
>
> Thank you, in spite of all I said earlier, I really like ‘local-file’!

Commits 24e02c2 and 8476583 change ‘hosts-file’ and ‘sudoers’ as
discussed.  Are there others left or can we close the bug?

Thanks!

Ludo’.

bug#20720: Inconsistency in text fields for 'operating-system'

[Alex Kost]

Ludovic Courtès (2015-06-05 23:47 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-06-05 15:30 +0300) wrote:
>
> [...]
>
> Now, of course the solution will be for ‘guix system reconfigure’ to
> restart services that can be restarted.  The goal is not to force people
> to reboot for changes to take effect. :-)  That “just” has to be done.

Yeah, that will be a great feature some day :-)

>>> I’ll prepare a patch for that and report back.
>>
>> Thank you, in spite of all I said earlier, I really like ‘local-file’!
>
> Commits 24e02c2 and 8476583 change ‘hosts-file’ and ‘sudoers’ as
> discussed.  Are there others left or can we close the bug?

My needs are completely satisfied now, thank you very much!  The bug can
be closed I think.

-- 
Alex

bug#20720: Inconsistency in text fields for 'operating-system'

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> My needs are completely satisfied now, thank you very much!  The bug can
> be closed I think.

Great, thanks!

Ludo'.