bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

[...]

> also, seems like it didn't register in this discussion, so i press it
> once again: if the default/unspecified value is a symbol (any symbol),
> then those configuration fields, whose type is set to be of symbol,
> will not error when they are left unspecified. (see the
> FIELD-SANITIZER: it simply does a (IF (PRED VALUE) ...) check, which
> doesn't fail because 'UNSET satisfies SYMBOL?). i should have added a
> unit test for this...

OK, I've reread this, and it is indeed a risk, that 'unset could leak in
the case of a serializable configuration making use of a maybe-value
field of type maybe-symbol.  I've added the unit test suggested as
97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected
to fail').  Luckily no current service uses that.

I think the tension between serializable vs non-serializable unspecified
values comes from the two kind of usages of define-configuration: one is
to generate config files, in which unspecified means "nothing", and
shouldn't touch disk, while in the case it's used as a more general data
type (define-configuration/no-serialization), there is value in being
able to lower that data type on the build/target so that things can be
lazily computed where needed, without loss of information.

We should add one more unit test to exercise this last usage in action
(currently only jami-service-type makes use of that, but I have an
upcoming Xvnc service that benefits from that as well).

Thanks,

Maxim