From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id qIJ6CuQHU2EqwwAAgWs5BA (envelope-from ) for ; Tue, 28 Sep 2021 14:17:40 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GH7wBeQHU2HrWAAA1q6Kng (envelope-from ) for ; Tue, 28 Sep 2021 12:17:40 +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 AC845D21E for ; Tue, 28 Sep 2021 14:17:39 +0200 (CEST) Received: from localhost ([::1]:60060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVC3G-0007J3-OD for larch@yhetil.org; Tue, 28 Sep 2021 08:17:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVC2l-00074f-8l for guix-devel@gnu.org; Tue, 28 Sep 2021 08:17:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41442) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVC2k-0003QU-6s; Tue, 28 Sep 2021 08:17:06 -0400 Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=60480 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVC2j-0008UK-Ac; Tue, 28 Sep 2021 08:17:06 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Andrew Tropin Subject: Re: On the naming of System and Home services modules. References: <87zgsei5ta.fsf@trop.in> <87pmtarnrh.fsf@yoctocell.xyz> <87pmsz9hrj.fsf@gnu.org> <871r5eqtu2.fsf@trop.in> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 7 =?utf-8?Q?Vend=C3=A9miaire?= an 230 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 28 Sep 2021 14:17:03 +0200 In-Reply-To: <871r5eqtu2.fsf@trop.in> (Andrew Tropin's message of "Fri, 24 Sep 2021 11:08:21 +0300") Message-ID: <87ee98dhds.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, Xinglu Chen 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=1632831459; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Pg5c+POycmxK069Ks7nJ4OtVMFj7Os58p5OJ9adfJcs=; b=TOhEi8nAPJZyaG/c7eP1+PvfK3yyioUg0Z8ENF3HcWMgiJ6Lp+XQJX9BgU+qS1c0jTmvTN u+VIGTMB87A1PsHUrUkjO5nzny3JAYacLGZDpHkEP+nWWEy8PEy0MfrjeeyK9a0USx6yCu pG3BauhmKpZenBcoH6hG18smS/6Lb6pB9AXsbzxZHGoi+8TVn3JngOkx72eYLixCE6b1ua kMmq5I08GZy5wcyOCOdPdV1XDLiv41RSULTVfuZBQiex9if8jlQt0qr+G6B8IRzl1vd/93 eeaD4fb/dB82cR6XawdYZvtoT9VZkCwrlfOyEJNey9Rw6E6r4gTEy6wTUkXPOg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632831459; a=rsa-sha256; cv=none; b=P7jEDKLMXXQDq+nxfMkBbzq4F6XBRcdLU/6LR4eH/nFpREpHtA6P7THTcbGBxz/23SfWWw EbKFr/sCrHWbh/uJT924Cl7bYboJS1RRhQdsxUpVBrcWxm1F/BbWZuMVz3ZVExrGvRJcA0 QVAluuX8aaTN3pWCUQ2F0SWDfI2GoSnVn2IRrd6bt4VRvQMJySoATZVc4o0chIRYhD2pVH yw1IDIrmqObn4atYhDxRGnPWwYFDUzdX/bsbjdlvuopGXQ9d0/NpqApyuKAl0LtRv6xFQ9 34+yHM62T+7/BKTbsOS+wkLw+5Ap7jdmuZ89/rAb8OH/2WdC3+8EpzfYWlAvlA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: -2.90 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: AC845D21E X-Spam-Score: -2.90 X-Migadu-Scanner: scn0.migadu.com X-TUID: +L4r4OCzAVLt Hi Andrew, Andrew Tropin skribis: > On 2021-09-23 22:08, Ludovic Court=C3=A8s wrote: [...] >> Silly question, but why do we need to have two different configuration >> record types in the first place? To be clear: you=E2=80=99ll have to be very convincing as I know all too we= ll the cost of maintaining such a thing :-) and can already foresee that this would also be annoying to users. > 1. Different fields (for example system services in many cases wants to > know the username, which will be used to run process from, home services > will probably use the user's username and won't rely on this field, home > services on the other hand can have something like xdg-flavor? or > anything else unrelated to system services). > > Even if fields are not conflicting with each other, it's very likely > that it will introduce a confusion: user of Guix Home on foreign distro > will be guessing why there is a field in configuration record, which > doesn't make sense for a home service. Do you have specific examples? The user name example isn=E2=80=99t a convi= ncing one for me, at least not in the abstract. > 2. Different default values. $HOME/mail or /var/spool/mail? Even if we > can technically bypass those problems, semantically the values will be > incorrect. Again, any specific example? How frequently does this problem occur? It could be solved, say, by having a =E2=80=98home-service?=E2=80=99 Boolea= n in the config, which default values would take into account. >> 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 main= tain. >> >> Would that be feasible? (Apologies if this has already been discussed!) > > I find records to be a very rigid and hard to reuse We can discuss the suitability of records, but we need an immediate solution to the problem, especially now that it=E2=80=99s in =E2=80=98maste= r=E2=80=99. Duplicating configuration records for each and every service could have a huge maintenance cost that we=E2=80=99re probably not willing to pay. >> 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? > > Not sure what you mean here, can you share a link to the proposal or > elaborate one more time, please. I can=E2=80=99t find the message anymore. The suggestion is to have helper= s to =E2=80=9Crewrite=E2=80=9D the System service type graph for Home, so you co= uld do things like: (define home-profile-service-type (system->home-service-type profile-service-type)) (define home-mcron-service-type (system->home-service-type mcron-service-type)) because fundamentally, these two things are the same as their System counterpart, except that they graph is rooted in =E2=80=98home-service-type= =E2=80=99 (or whatever it=E2=80=99s called) instead of =E2=80=98system-service-type=E2=80= =99. Of course there are exceptions, but it may be possible to do that for quite a few services. Thoughts? Ludo=E2=80=99.