From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sG78DD3UTWFsNQAAgWs5BA (envelope-from ) for ; Fri, 24 Sep 2021 15:35:57 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id aA2+CD3UTWG3XQAA1q6Kng (envelope-from ) for ; Fri, 24 Sep 2021 13:35:57 +0000 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 D3C24374F2 for ; Fri, 24 Sep 2021 15:35:56 +0200 (CEST) Received: from localhost ([::1]:34452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTlMp-00068W-3z for larch@yhetil.org; Fri, 24 Sep 2021 09:35:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTlMZ-00067E-6x for guix-devel@gnu.org; Fri, 24 Sep 2021 09:35:39 -0400 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:35714 helo=mail.yoctocell.xyz) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTlMV-0007aM-QC; Fri, 24 Sep 2021 09:35:38 -0400 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1632490527; bh=sFPURyivl45fHru4QyXP7uvZhLXd675ZTOCqChq3MO0=; h=From:To:Cc:Subject:In-Reply-To:Date; b=W3rkRfuib/XNZ9iy7n5+RBYCMXmDPqdeTFYzOE9MvOobWSlNca1oxWTFSCxYwwGB/ IFFw4dPI1CQxcspzSDIllqOTK+/nnBNyqmsGmtrbNSkTWY4VN+8+TetxoYgoQLRadS lzTrLPRxaJGLQIXfg7xFZQcYmzZO49lg3tkVJxhQ= To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Code sharing between system and home services (was Re: On the naming of System and Home services modules.) In-Reply-To: <87pmsz9hrj.fsf@gnu.org> Date: Fri, 24 Sep 2021 15:35:14 +0200 Message-ID: <87tuiajdv1.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=87.96.130.155; envelope-from=public@yoctocell.xyz; helo=mail.yoctocell.xyz X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 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, FROM_SUSPICIOUS_NTLD=0.499, PDS_OTHER_BAD_TLD=1.997, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, Maxim Cournoyer , Andrew Tropin Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1632490557; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=FMAZ6CLG5znNQy0b0qXE6Tl2OoO1chxL8zQf47AP8J8=; b=Kg0JLJyLw6vYBdaOLoRIdZWPQ9ruKSVsVGyrFXrAEalDgt0lzW2orQGv2bwFAYBzu4tjmz PuS8vyivTGap73kwl2q0/6U5P4UcAotTLGUWHYPKPe0q+2aAe4OO8lvV+kY6bv00hY0A+F JPHr1SEFyRYNGdGdmyyRXifa7hF74PhqNoExwzVGpL1WusC4JNzGM3iLriZ0tqDuhlOr/M gVzx0kvwMt4lgtQhMFrOTV8gcXAgb0ihqLl8myYJbcHfKgzPYd8ApYsIf52hha0aOeYuAd 2fN97hDt2A6+4HxD7XF6y/9BGTeB9W95LwvLzu0GE19YyOVcPGf44KQM6ZygpQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632490557; a=rsa-sha256; cv=none; b=ZDm0l+cEQ5hlFRqS0hYx/gUEXsluj/dcKXYPYFXJSED5AyjknBB8RcxEGrOj/dVdIMkTae +xIRd9pXonztnuCpvvQ7IGwZ5eT84wdej7OSGAZEUCvT1RObtnN1kgGNKsJd+XNfVetrbG IwndN7d8LBHWJOy7M4cjzANHwg0J9m/Y5M5ovcgLD2zCHitRCiQOe/8TVlEB4hBHFRDpJI emYKO/gtYA1vp7NoTX5mmGawZTvaaUSpOwANoPqoq/FPZfH3CtHcvGLdC7M14lC/3Cs09Q 4dHX1k1byc3JoDZoNwGwzcIEiI1D3GAG5b+q/PtfOJ0XtQQEBRbUUVDB8EA/1g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=yoctocell.xyz header.s=mail header.b=W3rkRfui; dmarc=fail reason="SPF not aligned (relaxed)" header.from=yoctocell.xyz (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -3.39 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=yoctocell.xyz header.s=mail header.b=W3rkRfui; dmarc=fail reason="SPF not aligned (relaxed)" header.from=yoctocell.xyz (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: D3C24374F2 X-Spam-Score: -3.39 X-Migadu-Scanner: scn0.migadu.com X-TUID: bX1bY/Kk8Yd7 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 23 2021, Ludovic Court=C3=A8s wrote: > Hi, > > Xinglu Chen skribis: > >> Some services might be useful to have in both Guix System and Guix Home; >> for instance, Guix System currently has a service for configuring >> Syncthing, and I think it makes sense to also have one for Guix Home, >> this would mean that people not using Guix System (me :-)) could also >> have Guix manage Syncthing. With the current approach, we would have to >> copy and paste quite a bit of code, and if the Syncthing service for >> Guix System changes, then the one for Guix Home might have to change as >> well. > > Silly question, but why do we need to have two different configuration > record types in the first place? The problem is that the configuration records for system and home service don=E2=80=99t necessarily have the same fields. The Syncthing serv= ice for Guix System has a =E2=80=98user=E2=80=99 and a =E2=80=98group=E2=80=99 = field, which is not really of any use in Guix Home, as the only user would be the user invoking =E2=80=98= guix home=E2=80=99. > Sharing configuration between Home and System sounds important to me: it > means users can easily move services from one to the other, which is > pretty big deal. It also means we=E2=80=99d have much less code to maint= ain. Agreed, that=E2=80=99s what I would like to see as well. > Would that be feasible? (Apologies if this has already been > discussed!) Since it might not make sense to have the same records fields for a system service and home service, I proposed (in the mail you replied to) a =E2=80=98define-configuration=E2=80=99 form that would generate a configu= ration record for a system service and optionally one for a home service, without having to maintain two records separately. =2D-8<---------------cut here---------------start------------->8--- (define-configuration syncthing-configuration (package (package syncthing) "Syncthing package to use.") (arguments (list-of-strings =E2=80=99()) "Command line arguments to pass to the Syncthing package.") (log-flags (integer 0) "Sum of logging flags.") (user (maybe-string 'disabled) "The user as which the Syncthing service is to be run." (home-service? #f)) ; not for Guix Home (group (string "users") "The group as which the Syncthing service is to be run." (home-service? #f)) ; likewise ^^ (home (maybe-string 'disabled) "Common configuration and data directory.") (home-service? #t)) =2D-8<---------------cut here---------------end--------------->8--- It would generate and . The only difference being that doesn=E2=80=99t have a =E2=80=98user=E2=80= =99 and a =E2=80=98group=E2=80=99 field. It=E2=80=99s probably going to be quite complicated, so it would be good to= get some feedback/thoughts on it. Cc Maxim since he has done some work with (gnu services configuration). Also, it=E2=80=99s probably time to properly document (gnu services configuration) in the manual. ;-) > Also, I proposed earlier a possible way to generate a Home service type > from the corresponding System service type=E2=80=94or, IOW, to generate a= Home > service type graph from the System graph. Does that sound feasible? I am not sure exactly what you mean here, could you elaborate? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmFN1BIVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5jgsP/jJs+vHjjfUpSAbjpODwL3nkwv5a hEV2StyjsnDXiIHPkL2G0QtEGCY921x9f1uQGWFdRz+Ntt1iXZ2a7JUerVbBynE6 VD5JdnoI8LkyJpYApAZf7V2Lr+l2C6kvSqv92P5opEWFaCSAngXVb1mHVpOlbZkz MUPPclsbkGW47DI5nRDHcL+59hqx1kEhm9y+SbmVH1KI5vxJ0xJ2ZzCXKWH8Tnlf Wd+jEdbUPKKBCq5/Qfcht3l4N+zRX4jVdGTo8h1B1CFqiY1Fx1bAVSZdToo8QKyE DB2DPv3OhHYlxkuPiRAQKmQVxI1B1oTyEbyC+3QgbRzh9FMPxHdj7anp5XdZoUHi wJYcFBGqCq8Q/Tw822BIiXEbo+uOIkXlBeGC9nkYrfw9MA0xIB9q+hHVEGUZXopQ AVJRG7ptgsKLcf8hjjkGEy376Dpqpgdfgpk3VbLref0OBkqYouozKZSwHMJeXuJz zSmFDwdI++u+QIeHydbplYbta8L3OiAswXhe3eUpxUd0O13i8F+Bjpn7/PYguKEW E8DQ7ovNMuY7wHSl9BaYKLsTLsvP45LDO+9qqoVm6YgmflqFNTzjZ0BAzgF8qzFE IrJ7RtIY0NyjKk//Tlm/Ml6rDnxANN9i1UbFmq5v35J1zV1RQUIFjCYda8qfgbvt Jb0ZSPYiImwynmIQ =ERXv -----END PGP SIGNATURE----- --=-=-=--