Re: Divvying up service definitions

[Bruno Victal <mirai@makinata.eu>]

Hi Felix,

On 2023-10-24 18:54, Felix Lechner wrote:
> The number of services we offer strikes me as sufficiently small for
> your "unsorted" scheme to remain easy to navigate.

I can see your point here if we're to do estimates and interpolation
based on the growth of the services so far although I don't think it
would hurt to organize them.

> Also, we already use this scheme for several services---such as rsync,
> ssh, vnc, certbot, certbot, cgit, cups, ldap, lirc, sddm, avahi, mcron,
> spice, auditd, sysctl, getmail, lightdm, and syncthing. I am not sure
> it's worth a long discussion.

Agreed, the crux of the discussion is splitting service-definitions into
their own modules.
Sorting them can be decided later. (in a separate discussion if necessary)

> Moreover, categorizations are often ambigious and can make it harder to
> locate a particular service definition.
> 
> While some services may remain narrowly bundled---as they are in nfs,
> dbus, herd, hurd, samba, docker, ganeti, and shepherd---categorizations
> often exist purely in the eye of the beholder. For example, does
> Kerberos belong into its own category, as it does now, or is part of
> 'authentication', or perhaps 'security'?

I dont think there's any problem wrt categorization. For your Kerberos
example, either would be fine as they're not mutually exclusive.
(though I'd lean towards 'authentication' here)

We already see something similar with gnu/packages/… and it hasn't caused
much pain I believe. (the concerns there are mostly about cyclic modules
which I don't believe is relevant for services)
Again, the categorization doesn't have any impact on the code itself and
its purpose is to collect the modules into something more manageable so
even outright miscategorizations don't have any impact on the functionality
of the code.

> For a transitional period, we could perhaps provide intermediate modules
> in old places which re-export the service definitions that were moved,
> but I'm not sure it's really necessary.

Absolutely, there's mechanisms for re-export and we can already see their
use. (e.g. gnu/system/shadow.scm)

-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.