Re: Divvying up service definitions

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

>> * Splitting this as gnu/services/dovecot.scm.
>>   We keep it compatible with 'use-service-modules' at the cost of having
>>   a multitude of files under gnu/services, without any logical grouping
>>   (messy).
>
> That's a great initiative!  I agree that multiple 'define-configuration'
> services per file can be a bit messy, having to use prefixes everywhere,
> making the definitions more verbose.
>
> I don't have a strong preference of the caterogization of services, but
> would perhaps prefer the first one (gnu/services/mail/dovecot.scm),
> which could then make it easy to offer some interface as
> gnu/services/mail.scm that'd re-export all that is needed (would that
> work, or reintroduce the same top-level clashes?).

I’m all for “cleanups” as proposed, and I don’t have strong preferences
on how to do that.

I’d like us to make sure, though, that this is made in a
backward-compatible way: these module names and exported bindings are
part of the API that users refer to from the OS config file.  Renaming
things typically breaks user config, and updating it to use the new
names can be tedious if there are no messages explaining what to do.
‘define-deprecated’ helps, but perhaps we need something a little bit
more fancy now.

(It would be great if we could reach a level of backward-compatibility
close to what Emacs does: nice deprecation messages, recording when a
particular binding was introduced, and generally changing user-visible
things rather slowly.)

Ludo’.