GNU bug report logs - #20720
Inconsistency in text fields for 'operating-system'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20720 in the body.
You can then email your comments to 20720 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex Kost <alezost <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: Inconsistency in text fields for 'operating-system'
Date: Tue, 02 Jun 2015 17:58:46 +0300

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

Message #8 received at 20720 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alex Kost <alezost <at> gmail.com>
Cc: 20720 <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Wed, 03 Jun 2015 11:52:41 +0200

Alex Kost <alezost <at> 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’.

Message #11 received at 20720 <at> debbugs.gnu.org (full text, mbox):

From: Alex Kost <alezost <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 20720 <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Thu, 04 Jun 2015 17:43:55 +0300

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

> Alex Kost <alezost <at> 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

Message #14 received at 20720 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alex Kost <alezost <at> gmail.com>
Cc: 20720 <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Fri, 05 Jun 2015 14:30:35 +0200

Alex Kost <alezost <at> 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’.

Message #17 received at 20720 <at> debbugs.gnu.org (full text, mbox):

From: Alex Kost <alezost <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 20720 <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Fri, 05 Jun 2015 16:27:39 +0300

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

> Alex Kost <alezost <at> 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

Message #20 received at 20720 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alex Kost <alezost <at> gmail.com>
Cc: 20720 <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Fri, 05 Jun 2015 22:47:25 +0200

Alex Kost <alezost <at> 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’.

Message #23 received at 20720 <at> debbugs.gnu.org (full text, mbox):

From: Alex Kost <alezost <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 20720 <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Sat, 06 Jun 2015 20:38:53 +0300

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

> Alex Kost <alezost <at> 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

Message #28 received at 20720-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alex Kost <alezost <at> gmail.com>
Cc: 20720-done <at> debbugs.gnu.org
Subject: Re: bug#20720: Inconsistency in text fields for 'operating-system'
Date: Sun, 07 Jun 2015 17:16:33 +0200

Alex Kost <alezost <at> gmail.com> skribis:

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

Great, thanks!

Ludo'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.