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

[ludo@gnu.org (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’.