GNU bug report logs - #56799
(gnu services configuration) usage of *unspecified* is problematic

Previous Next

Full log

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Attila Lendvai <attila <at> lendvai.name>
Cc: 56799 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified*
 is problematic
Date: Tue, 09 Aug 2022 22:17:27 -0400

Hi Attila,

Attila Lendvai <attila <at> lendvai.name> writes:

>> i'm obviously not aware of the entire complexity here, othrwise
>> there wouldn't have remained a bug... but regardless of the actual
>> API/value used, i don't see how any of this could work without the
>> service code explicitly checking for the unspecified value for
>> fields that have a maybe type (i.e. whose type allows the value to
>> be unspecified). i think using a symbol instead of unspecified only
>> pushes the appearance of the symptoms farther away both in time and
>> space (otherwise there should have been a trivial fix to this
>> without changing unspecified back to 'unset).
>
>
> sorry, i was wrong/slow here^.
>
> i think i finally understand what the original issue was that triggered the rollback:
>
> the *UNSPECIFIED* value cannot get through the GExp
> serialize/deserialize operation between the host/builder (or how do we
> call it?) and Shepherd. the checks in the service code that handle the
> unspecified field values only happen when Shepeherd is executing the
> deserialized GExp's.

That's the issue, yes!  the *unspecified* value cannot cross the
host/build border, which forces someone to pre-compute all things before
serialization happens, which is inconvenient at best in some scenarios I
hinted at (a recent one is defining inetd-style services, which
endpoints need to be computed on the target (inside the service gexp)).

> the fix i would propose is to smarten up GExp serialization to handle
> whichever value we use as the marker, be it 1) *UNSPECIFIED*, or 2)
> Nothing from srfi-189, or 3) a record instance that we
> define/instantiate ourselves.

That's what I first attempted, without success.  That *unspecified*
expands to some random object on every usage seems meant to discourage
its usage as a specific value (its name, too!)

> i don't recommend 3). we should rather use srfi-189 then, because it
> sandardizes widely known concepts

srfi-189 sounds fancy, but how would it be better than the 'unset
symbol?  Could you please restate the problems faced when using a
symbol?  Would it be lowerable into Gexp, unlike *unspecified*?  To me,
in Guile this means having a readily implemented reader syntax.

> so, would you accept a patch that implements 1) or 2) ?

As I mentioned earlier, the specific value used for a maybe value is an
implementation detail, or should be made one, in my opinion.  So it
doesn't matter to me, as long as it makes writing services convenient
and passes all the tests (I recently augmented the jami-service-type
test which such a case to avoid any regressions).

Thanks,

Maxim

Previous Next

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