From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +Ki6HBM8xl5CVwAA0tVLHw (envelope-from ) for ; Thu, 21 May 2020 08:30:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id eIuOGBM8xl5oLQAAbx9fmQ (envelope-from ) for ; Thu, 21 May 2020 08:30:11 +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 D9D619404CD for ; Thu, 21 May 2020 08:30:10 +0000 (UTC) Received: from localhost ([::1]:33828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbgaf-00056y-PB for larch@yhetil.org; Thu, 21 May 2020 04:30:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbgaZ-00056p-3r for guix-patches@gnu.org; Thu, 21 May 2020 04:30:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:43740) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbgaY-0005pA-R1 for guix-patches@gnu.org; Thu, 21 May 2020 04:30:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jbgaY-0007Xm-NM for guix-patches@gnu.org; Thu, 21 May 2020 04:30:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#35305] LightDM service Resent-From: L p R n d n Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 21 May 2020 08:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35305 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: Ricardo Wurmus Cc: brice@waegenei.re, 35305@debbugs.gnu.org Received: via spool by 35305-submit@debbugs.gnu.org id=B35305.159004974228900 (code B ref 35305); Thu, 21 May 2020 08:30:02 +0000 Received: (at 35305) by debbugs.gnu.org; 21 May 2020 08:29:02 +0000 Received: from localhost ([127.0.0.1]:55286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbgZa-0007Vt-95 for submit@debbugs.gnu.org; Thu, 21 May 2020 04:29:02 -0400 Received: from mout01.posteo.de ([185.67.36.141]:41468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbgZY-0007VX-4x for 35305@debbugs.gnu.org; Thu, 21 May 2020 04:29:01 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id B1EF516005C for <35305@debbugs.gnu.org>; Thu, 21 May 2020 10:28:53 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49SN7S4STZz6tmP; Thu, 21 May 2020 10:28:52 +0200 (CEST) From: L p R n d n References: <87zhooso9g.fsf@lprndn.info> <87imh9gnvy.fsf@lprndn.info> <87k11m2hqx.fsf@elephly.net> <87zhahcfgh.fsf@lprndn.info> <878shz38bf.fsf@elephly.net> <87o8qtzd71.fsf@lprndn.info> <87k116e3ee.fsf@elephly.net> Date: Thu, 21 May 2020 10:28:51 +0200 In-Reply-To: <87k116e3ee.fsf@elephly.net> (Ricardo Wurmus's message of "Wed, 20 May 2020 22:51:21 +0200") Message-ID: <87tv09zo70.fsf@lprndn.info> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -2.6 (--) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -0.01 X-TUID: 9pPMtn/QtymB Hello, Ricardo Wurmus writes: > Hey, > > I=E2=80=99m very sorry for the delay. Again, there's no hurry. ;) > What took me so long is that I=E2=80=99m conflicted about how to move for= ward. > On one hand I really don=E2=80=99t want to delay this. I think your patc= hes are > a great and important addition to Guix. On the other hand I feel that > the relationship between these new components isn=E2=80=99t quite right. > > It still doesn=E2=80=99t feel quite right to me that there=E2=80=99s a > lightdm-service-type and an independent > lightdm-gtk-greeter-service-type. I know that there can be any number > of greeters, but only one will be used with lightdm-service-type > dependent on the string value of greeter-session. This leads to > potential misconfiguration as we don=E2=80=99t (and can=E2=80=99t) valida= te this string. Just to clarify, as per my understanding, there can be multiple `greeter-session fields defined. It's not a global value but a per seat one. Each seat should be able to use a different greeter, I think. Personally, I have a very standard use whith only one seat so there are no questions in that case. However there might be use-cases where it's needed. I CC bricewge, they might be more knowledgeable on this issue. > It also feels wrong to me to have a global directory as the only > location for greeter desktop files, which means that all greeters must > be installed globally. Isn't using packages as inputs of `greeter-session solving this issue? We can collect them from seats and string-join them into the `greeter-directory field. > What I envision is something like this: we only have a single > lightdm-service-type and it has a field =E2=80=9Cgreeters=E2=80=9D, which= by default is > a list of just one item: a record containing the > lightdm-gtk-greeter and its configuration. > > Other greeters could be added; they would all be record values of type > and come with their own extensions of the > ligthdm-service-type. > > The lightdm-service-type would go through each of the greeters in the > list and apply their specified extensions to itself. If I understand correctly, the main difference would be that the greeters would be defined from within the lightdm-service (as a list of rec= ords?), right? The current implementation was chosen to avoid too much field nesting but I don't mind. Also, you can have a look at the previous implementation (see mail from 19th of March). It lacks seats and some featurse but it looks a little closer to what you're describing. It might give some ideas. > The reason why I haven=E2=80=99t implemented this yet is because a) I don= =E2=80=99t want > to break what already works with your patches and b) I don=E2=80=99t know= if > that=E2=80=99s ultimately a clearer implementation. > > I feel that this would be a more intuitive configuration and result in > clearer relationships between the display manager and its swappable > components. It would also allow for better defaults (so less > configuration needed) and avoid the problem of stringy types that are > easy to get wrong. > > Maybe we are already really close to this solution, though: maybe the > proposed =E2=80=9Cgreeter=E2=80=9D field could simply accept service type= s like the > lightdm-gtk-greeter-service-type you already defined. We're close. :) Just curious here, if we use a list of services (for example) as input of the greeters field, how do we take care of it? Can we "merge" the different services into the lightdm one? If it's possible, this might be a good solution. > I=E2=80=99m going to play with this a little bit more, but if this doesn= =E2=80=99t lead > anywhere I=E2=80=99ll merge the current version. > > My apologies for delaying this! Everything is going a lot faster than it was a few months ago so it's already fine. Have a nice day, L p R n d n