GNU bug report logs - #59423
Invalid 'location' field generated in dovecot configuration

Previous Next

Package: guix;

Reported by: Pierre Langlois <pierre.langlois <at> gmx.com>

Date: Sun, 20 Nov 2022 22:11:01 UTC

Severity: important

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>, 59423-done <at> debbugs.gnu.org
Subject: bug#59423: Invalid 'location' field generated in dovecot configuration
Date: Sun, 04 Dec 2022 16:43:46 -0500
Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Thanks for this extra bit of information and for spotting this usage.  I
>> think "location" is likely to conflict for the general purpose
>> 'define-configuration' generated records, so I've renamed the "location"
>> *accessor* to "source-location".
>
> Thank you.
>
> It wasn’t my preferred solution¹ but I think it’s a good one.
>
> ¹ https://issues.guix.gnu.org/59423#15-lineno81
>
>> In the near future I want to migrate more service configurations to the
>> 'define-configuration' machinery, to benefit from its useful
>> self-validating property.  For now I wouldn't feel at ease doing so
>> unless raw record matching (not yet using 'match-record') works the same
>> way, since we still have many occurrences making use of that (often via
>> match-lambda).  For that reason, I prefer to not revert the record
>> layout until we've gotten rid of all the match-lambda matching record
>> fields directly (which will take some time).
>
> Right, especially given that ‘match-record’ was added in 2017.  :-)

Hehe!  I had started adapting all the match-lambda, and got overwhelmed
by the changes needed.  So I think progressively (i.e., small) be easier
to review or revert in case of errors.

> We’ll have to discuss the implications of a possible move to
> ‘define-configuration’.  For example, ‘define-configuration’ cannot
> report missing field values (for fields that lack a default value) at
> macro-expansion time, contrary to plain ‘define-record-type*’.  Anyway,
> future work!

OK.  That's optimization work rather than an impediment to migrate
though, right?  If so, I think the value for users of having errors on
invalid field types outweighs run time efficiency :-).

-- 
Thanks,
Maxim




This bug report was last modified 2 years and 166 days ago.

Previous Next


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