From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id UPQdIAwFOGWvOgEA9RJhRA:P1 (envelope-from ) for ; Tue, 24 Oct 2023 19:55:24 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UPQdIAwFOGWvOgEA9RJhRA (envelope-from ) for ; Tue, 24 Oct 2023 19:55:24 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 65E173CD79 for ; Tue, 24 Oct 2023 19:55:20 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lease-up.com header.s=2017 header.b=fe4VreuJ; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1698170120; a=rsa-sha256; cv=none; b=FImn4IXNacaz+W3nRw3VFuJFuCtUBojYT6k0j2G7H5nCRQYrd+VEEJsBJfh4WiFB0P5G8h E/Sx50uRbMx6tENGVYLdg/GYixY2f+LDd/8v0UUDirM94gwYo+ePoOTqarVFvrFL1IE0Il Lx8RTvqqI9nFMP9bcdU+fkADtVM6OfD3YfKk2MjEWwRaPtazweA7mjcscS+uhSRHk05agB Z8u0hij4OOLCR3n5iMBJvb++AkgWDhKTa60gcmSO8qYa7ovhb0zrBtYZKx7765wSYxwPq4 xA5L/3OFAhusNDP9tJDKVQqDxrt7Fa6ocrkX2qGRajZhIzeJMJIHb1+jWtdljg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lease-up.com header.s=2017 header.b=fe4VreuJ; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1698170120; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=sVtSPsfK0qnIs12a2tQTpN+SlchI7SPPJgkaWFEGU3I=; b=YZb95leZLDv1O0pXWJZrivTSWchgQHdYmW3N5206kcegIx+bLqF+sDi6qD00Lz4s0KP/Np mUasGhT3yp7scHNPFVIbITBwKrVfGqqWRSAR6xbNOogN1Lf21hzhsCI8K0VxV+xdCCjfTi DX0nwRLSqzHMriJaI6Ef8ZtBs6SM0LatrCPlUJl8JiqOFkeZFZV6PLX16sf5t6vq3h6Ej2 MvXpV3w8E69/srCs7XMh1PMpg6GFwO+lwHZZGdlw/GRzWL2FFe55xS2pUZnTHhUhsmtUZ8 Lek2Bu29qquXddjFNbh9Mrm0c+7Io/KnXfRN8DmWTa0qhI9nXI951ZNTjqpLtg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvLc0-0005ts-4V; Tue, 24 Oct 2023 13:54:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvLbm-0005t8-CM for guix-devel@gnu.org; Tue, 24 Oct 2023 13:54:27 -0400 Received: from sail-ipv4.us-core.com ([208.82.101.137]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1qvLbk-00007r-GG for guix-devel@gnu.org; Tue, 24 Oct 2023 13:54:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=NuF4HX8p/2RfjiF BezbqyFPRSdDuA74CwODyfn8sRog=; h=date:references:in-reply-to:subject: cc:to:from; d=lease-up.com; b=fe4VreuJNodjyyPuI+A6u9eAn0VVdx7zo9TJmO/f 5liyKUa7ICGd/iNO/p1vXGFM2ajv1jOBi1KhCBV7Ci+L3PwbIAQcCI6OsFyc6tQyx/IzOt rZW7+tg1Ws3fsy34R2XaxcThyNztHK3KSAYBLs8NhDvIg4uDTPqroG/aPNF5k= Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id e1fbe773 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); Tue, 24 Oct 2023 17:54:22 +0000 (UTC) To: Bruno Victal , guix-devel@gnu.org Cc: Subject: Re: Divvying up service definitions In-Reply-To: <878r7skrpx.fsf@makinata.eu> References: <878r7skrpx.fsf@makinata.eu> Date: Tue, 24 Oct 2023 10:54:21 -0700 Message-ID: <87zg07dhyq.fsf@lease-up.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=208.82.101.137; envelope-from=felix.lechner@lease-up.com; helo=sail-ipv4.us-core.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Felix Lechner From: Felix Lechner via "Development of GNU Guix and the GNU System distribution." Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -1.91 X-Spam-Score: -1.91 X-Migadu-Queue-Id: 65E173CD79 X-TUID: XH82fK9c+pJq Hi Bruno, On Tue, Oct 24 2023, Bruno Victal wrote: > Further complicating things is > 'define-maybe', whose use monopolizes the predicate and serializers for > a particular service definition. I've dealt with that in the past and support your effort. > * 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 The number of services we offer strikes me as sufficiently small for your "unsorted" scheme to remain easy to navigate. 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. 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'? In short, I would proceed and split the services if there is no further comment on your request. It will make development easier. 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. Thank you for your clean-up efforts! Kind regards Felix