unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Attila Lendvai <attila@lendvai.name>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 56799@debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: bug#56799: (gnu services configuration) usage of *unspecified* is problematic
Date: Mon, 08 Aug 2022 23:35:03 +0000	[thread overview]
Message-ID: <JjWl8egYCQ-skQpPHR-gw-N0Hznkf5DHSr4EtLL6315ubP1sVuIhciJ9CU3JG4xwTEhGGwl7o7GfEIX5LxO5yD7YWzv2Ni42XDndcmkBCaQ=@lendvai.name> (raw)
In-Reply-To: <DdbGT0j9-gqlFuSurMIdU89IKjh-DSoHe40ILSbh7qW29r5TIeRwanmFtDimp2u3o42MKIgsjiw1wQ8gyB0q6NoXTZwADYwvY7YjHG5sEGo=@lendvai.name>

> 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/)





  reply	other threads:[~2022-08-08 23:36 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27 16:23 bug#56799: (gnu services configuration) usage of *unspecified* is problematic Maxim Cournoyer
2022-07-27 16:43 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-07-27 18:27   ` Attila Lendvai
2022-07-28 15:15     ` Maxim Cournoyer
2022-07-27 18:31   ` Maxim Cournoyer
2022-07-27 18:45     ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-07-27 19:09       ` Maxim Cournoyer
2022-07-27 19:45         ` bug#56799: [PATCH] services: configuration: Step back from *unspecified* Maxim Cournoyer
2022-07-27 19:46         ` bug#56799: (gnu services configuration) usage of *unspecified* is problematic Maxim Cournoyer
2022-07-27 20:20           ` bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input Maxim Cournoyer
2022-07-27 21:43             ` Maxime Devos
2022-07-28 14:58               ` Maxim Cournoyer
2022-07-28  4:41           ` bug#56799: [PATCH v3] " Maxim Cournoyer
2022-08-01  5:08             ` bug#56799: (gnu services configuration) usage of *unspecified* is problematic Maxim Cournoyer
2022-08-01 10:00               ` Maxime Devos
2022-08-01 12:46                 ` Maxim Cournoyer
2022-08-01 13:44             ` Ludovic Courtès
2022-08-01 16:55       ` Maxim Cournoyer
2022-07-28  4:55     ` bokr
2022-07-28 10:26       ` Maxime Devos
2022-07-28 15:09         ` Maxim Cournoyer
2022-08-01 13:49 ` Ludovic Courtès
2022-08-01 15:55   ` Maxim Cournoyer
2022-08-02  7:31     ` Ludovic Courtès
2022-08-02  8:45       ` bokr
2022-08-02 15:06       ` Maxim Cournoyer
2022-08-04 12:19         ` Ludovic Courtès
2022-08-07 22:44           ` Ludovic Courtès
2022-08-08 22:27           ` Attila Lendvai
2022-08-08 23:35             ` Attila Lendvai [this message]
2022-08-10  2:17               ` Maxim Cournoyer
2022-08-10  3:26             ` Maxim Cournoyer
2022-08-11 10:15               ` Attila Lendvai
2022-08-13  6:31                 ` Maxim Cournoyer
2022-08-13 16:47                   ` Attila Lendvai
2022-08-14  2:57                     ` Maxim Cournoyer
2022-08-16 14:00                       ` Attila Lendvai
2022-08-17 13:16                         ` Maxim Cournoyer
2022-08-17 16:00                           ` paren--- via Bug reports for GNU Guix
2022-08-10  0:43           ` Maxim Cournoyer
2022-08-24 12:40 ` bug#56799: [PATCH 1/5] services: configuration: Add a 'maybe-value-set?' procedure Attila Lendvai
2022-08-24 12:40   ` bug#56799: [PATCH 2/5] services: configuration: Add %unset-value exported variable Attila Lendvai
2022-08-24 12:40   ` bug#56799: [PATCH 3/5] services: configuration: Add maybe-value exported procedure Attila Lendvai
2022-08-24 12:40   ` bug#56799: [PATCH 4/5] services: Use the new maybe/unset API Attila Lendvai
2022-08-25  4:18     ` bug#56799: (gnu services configuration) usage of *unspecified* is problematic Maxim Cournoyer
2022-08-24 12:40   ` bug#56799: [PATCH 5/5] services: configuration: Change the value of the unset marker Attila Lendvai
2022-08-25  4:14     ` bug#56799: (gnu services configuration) usage of *unspecified* is problematic Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='JjWl8egYCQ-skQpPHR-gw-N0Hznkf5DHSr4EtLL6315ubP1sVuIhciJ9CU3JG4xwTEhGGwl7o7GfEIX5LxO5yD7YWzv2Ni42XDndcmkBCaQ=@lendvai.name' \
    --to=attila@lendvai.name \
    --cc=56799@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).