bug#48284: Dovecot <namespace-configuration> has two ‘location’ fields

bug#48284: Dovecot <namespace-configuration> has two ‘location’ fields

[Ludovic Courtès]

I just noticed this compiler warning:

--8<---------------cut here---------------start------------->8---
gnu/services/mail.scm:431:0: warning: shadows previous definition of `%namespace-configuration-location-procedure' at gnu/services/mail.scm:431:0
<unknown-location>: warning: shadows previous definition of `namespace-configuration-location' at <unknown-location>
--8<---------------cut here---------------end--------------->8---

I believe this comes from the fact that ‘define-configuration’
automatically introduces a ‘location’ field (for the source code
location of <namespace-configuration> instantiations), which clashes
with this one:

--8<---------------cut here---------------start------------->8---
  (location
   (string "")
   "Physical location of the mailbox. This is in same format as
mail_location, which is also the default for it.")
--8<---------------cut here---------------end--------------->8---

I think this was revealed by the fix in commit
dd0826fbf345dfe7289cf943ed2d29edc51d543f.

Probably the only sane way to address it is by renaming the field above.

Thoughts?

Ludo’.

bug#48284: Dovecot <namespace-configuration> has two ‘location’ fields

[Maxim Cournoyer]

Hi Ludo,

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

> I just noticed this compiler warning:
>
> gnu/services/mail.scm:431:0: warning: shadows previous definition of `%namespace-configuration-location-procedure' at gnu/services/mail.scm:431:0
> <unknown-location>: warning: shadows previous definition of `namespace-configuration-location' at <unknown-location>
>
>
> I believe this comes from the fact that ‘define-configuration’
> automatically introduces a ‘location’ field (for the source code
> location of <namespace-configuration> instantiations), which clashes
> with this one:
>
>   (location
>    (string "")
>    "Physical location of the mailbox. This is in same format as
> mail_location, which is also the default for it.")
>
> I think this was revealed by the fix in commit
> dd0826fbf345dfe7289cf943ed2d29edc51d543f.
>
> Probably the only sane way to address it is by renaming the field above.

We could also rename the define-configuration produced %location field
accessor to something more explicit such as $name-source-location
instead of $name-location, no?

I don't think that field is being used much at all, given it was
effectively broken prior to the above commit, so renaming it should go
mostly unnoticed.

Maxim