Divvying up service definitions

[Bruno Victal]

Hi,

As the gnu/services and gnu/home/services grow, I think we should
consider divvying the services into stand-alone modules or
subdirectories.

Consider the ⌜dovecot-service-type⌝ in gnu/services/mail.scm: as of
commit 'd22d2a05c389207f8cdcf824be7738b1499a987c' this service
definition is nearly 1600 lines long, with the remainder of the file
comprising of four other services with rudimentary support.

It becomes troublesome working with such amalgamations as it makes it
hard to keep track of the used modules and bindings, especially when
define-configuration is used since the serializing procedures might be
used by various service definitions. Further complicating things is
'define-maybe', whose use monopolizes the predicate and serializers for
a particular service definition.

Now, I'm not saying that we should go and split everything into its own
module, I'm saying that we should be allowed to split some of them if
convenient (all subjective but I believe we can see that working with a
monolithic file in the kilolines where the interactions aren't obvious
is not fun, and that's without bringing in the hygienic issues
surrounding define-configuration and define-maybe).

Some considerations (using dovecot-service-type as an example):
* Splitting this as gnu/services/mail/dovecot.scm.
  We preserve the logical grouping of the services (with the addition
  that, for extremely comprehensive definitions, these can be neatly
  organized into subdirectories. (same structure seen with gnu/*.scm)
  A drawback is that 'use-service-modules' might not work with this
  although I wonder whether 'use-service-modules' & co. provide any
  value if we are already doing '(use-modules (gnu) …)' to begin with.
  They look redundant IMO.

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

-- 
Thanks,
Bruno.