Re: [V2 PATCH 1/1] services: Add agetty service.

[myglc2 <myglc2@gmail.com>]

On 02/16/2017 at 02:06 Leo Famulari writes:

> On Tue, Feb 14, 2017 at 07:24:17PM -0500, Leo Famulari wrote:
>> This 'extra' is a time-saving kludge. I'll add fields for all of
>> agetty's configuration options once I'm satisfied that the service works
>> on GuixSD.
>
> Here's a patch that exposes (almost all) of agetty's command-line
> options.
>
> Is this the right way? Or would we rather wrap only the most
> commonly-used options, and leave an "escape hatch" as in the first
> version of the patch? If so, which options should we expose in Scheme?
>
> I'll wait for feedback before writing the documentation.

Hi Leo,

I think that what you have is great. With this in my system config ...

    (agetty-service (agetty-configuration
		     (tty "ttyS1")
		     (baud-rate "115200")))

... it works painlessly on a headless GuixSD server over IPMI.  I think
you can put a brief example in the doc, refer the user to the code and
the agetty man page for more info, and declare victory.

But let me digress a bit on this topic. What if, in situations like
this, Guix provided an easy way to export the "native config" generated
by Guix?

Then we could tell the user ...

1) If you want to know exactly what we are doing, export the native
config and read the native doc.

2) If you want features we don't support, export the native config, read
the doc, modify it, and feed it into the "native config hatch."

With this approach, we could implement and document only "key features"
with a clear conscience.  When we haven't implemented a feature the user
needs they will be no worse off that they were before. In fact, they
will usually be ahead, because Guix has taken care of the general
requirements and provided a sound starting point for a native config.