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

[Attila Lendvai]

> 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.

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.

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

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

2) has non-trivial uncertainties/complexities in making srfi-189 available in 
all the required contexts, and not introducing any bootstrap related issues in 
the process. because of that i would recommend getting to 2) by first 
implementing 1) and then working towards 2) -- if we want to use srfi-189 at 
all, that is.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“What's done to children, they will do to society.”
        — Karl A. Menninger (http://psychohistory.com/)