From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 16:51:45 2020 Received: (at 35305) by debbugs.gnu.org; 20 May 2020 20:51:45 +0000 Received: from localhost ([127.0.0.1]:54449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbVgn-0004Z6-GX for submit@debbugs.gnu.org; Wed, 20 May 2020 16:51:45 -0400 Received: from sender4-of-o53.zoho.com ([136.143.188.53]:21361) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbVgk-0004Yv-1C for 35305@debbugs.gnu.org; Wed, 20 May 2020 16:51:44 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1590007886; cv=none; d=zohomail.com; s=zohoarc; b=Z2yF/ge0pZfR4i3JEGQiOX+Zdi1mpxiOmQIaSFLevQx+rFUvDCHEYWJYb8N0QOMuZm4q1dyC1z6Ien7mjMCxPX4wFYdWNvJ1rCUf3AOIsvGxueS7NfQKF92P6tln1fNiwmpIqRVDbMV4cX2eZgR34CkBo0XsMf6NpksdJ6BIiZ8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1590007886; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=BzCDRhFGAGYaSTbd6KznpHp0Nmy8HouA6rFjxe4an0s=; b=LmKpiQHDZFzb9FR87LCrW7MVHz2xEb/5E18e3gC8iIlM4MCF6OY5KLn01cOM2GlqF9fmcmm5hPiqUiwAPe6OBGxeLHMvz1EY0lcwqtwHQQKGs5V5a3/3VMLfEFu8EiDJ+1DuHhioSZZntDaccNKnNuM7scOjcBpe8W+BVKB1ayQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1590007886; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:In-reply-to:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=BzCDRhFGAGYaSTbd6KznpHp0Nmy8HouA6rFjxe4an0s=; b=G2fLQP9w5pF7dnIk7lFLB0lf2CcqqZdnBcWMEVKkeTJVfXbp5VTtHXV/Ualfwoh/ ct6VZZbcC5eodA+vZ0Lz/8xcmHUpliYWO4G9uS1aI/4zPic2gGM+iq9jpRZoKxM0PmW OjB7+wpUdPLcDQzIWo7VwL7wibsI/vakUWvz2NAM= Received: from localhost (p54ad4b90.dip0.t-ipconnect.de [84.173.75.144]) by mx.zohomail.com with SMTPS id 1590007884644329.9297901107665; Wed, 20 May 2020 13:51:24 -0700 (PDT) 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> User-agent: mu4e 1.4.4; emacs 26.3 From: Ricardo Wurmus To: L p R n d n Subject: Re: [bug#35305] LightDM service In-reply-to: <87o8qtzd71.fsf@lprndn.info> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Wed, 20 May 2020 22:51:21 +0200 Message-ID: <87k116e3ee.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35305 Cc: 35305@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hey, I=E2=80=99m very sorry for the delay. What took me so long is that I=E2=80=99m conflicted about how to move forwa= rd. On one hand I really don=E2=80=99t want to delay this. I think your patche= s 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) validate= this string. 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. 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 b= y 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. 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 types = like the lightdm-gtk-greeter-service-type you already defined. 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! --=20 Ricardo