GNU bug report logs

#27155 [PATCH 0/2] Support service extensions on the "final" service values

PackageSource(s)Maintainer(s)
guix-patches PTS Buildd Popcon
Full log

Message #43 received at 27155@debbugs.gnu.org (full text, mbox, reply):

Received: (at 27155) by debbugs.gnu.org; 16 Mar 2025 11:47:35 +0000
From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 16 07:47:34 2025
Received: from localhost ([127.0.0.1]:45835 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1ttmSr-0005hC-HU
	for submit@debbugs.gnu.org; Sun, 16 Mar 2025 07:47:34 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:52638 helo=mail.ditigal.xyz)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rutherther@ditigal.xyz>)
 id 1ttmSo-0005fg-Nl
 for 27155@debbugs.gnu.org; Sun, 16 Mar 2025 07:47:31 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id f1377565
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Sun, 16 Mar 2025 11:47:21 +0000 (UTC)
From: Rutherther <rutherther@ditigal.xyz>
To: 27155@debbugs.gnu.org
Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final"
In-Reply-To: 20170530215850.7522-1-ludo@gnu.org
Date: Sun, 16 Mar 2025 12:47:21 +0100
Message-ID: <87bju16vue.fsf@ditigal.xyz>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
 i=@ditigal.xyz; q=dns/txt; s=20240917; t=1742125641; h=from : to : cc
 : subject : in-reply-to : date : message-id : mime-version :
 content-type : from; bh=qFtfE/fblWGAmmTQ7YAVV1/xXlrC9McRDzqmwn5ejk0=;
 b=SAnYyWW5eMThvtmImBoR4H9LGkCUnNk0Ih6CELBFwUgUHiLlnp8g2AEyOdFHQvwI1vsVW
 amH6m7Ru9qF+8Wf8yakF+Ts32d71mEkL3kTB8HcVY9sXTg4dMaaf/PdMaZohsMg4ex8Ppg0
 BxUq77J+e3zR3VeFNYCCcxRPlRamhJU=
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hello Ludo and Ricardo, what's the state of this? Why has
 this been abandoned? I am really missing a feature like this, so it pains
 me to see an abandoned thread that clearly states (and I agree) that this
 feature has been l [...] 
 Content analysis details:   (1.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.9 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ditigal.xyz (xyz)]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-Debbugs-Envelope-To: 27155
Cc: Ricardo Wurmus <rekado@elephly.net>,
 Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@gnu.org>
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hello Ludo and Ricardo, what's the state of this? Why has
   this been abandoned? I am really missing a feature like this, so it pains
   me to see an abandoned thread that clearly states (and I agree) that this
   feature has been l [...] 
 
 Content analysis details:   (1.4 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.9 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Hello Ludo and Ricardo,

what's the state of this? Why has this been abandoned?
I am really missing a feature like this, so it pains me to see
an abandoned thread that clearly states (and I agree) that this
feature has been long overdue, but now it's been even 8 more years longer!

For example, I would like to change the home mcron shepherd service so that it gets
a wayland display env var. Currently it is possible to modify leaf services
somewhat, as I can just override the service-type and change the
service, but this won't be working with non-leaf one as the original
service-type is extended. This complicates the process by a lot.

I think that if this was merged, it would be possible to start adding
other functions to guix that would be modifying shepherd services,
ie. some sort of a general modify-shepherd-service and then on
top of it functions to modify specific things, like dont-autostart-shepherd-service.

I am willing to put some work into this just say
what's missing here, because I don't know (apart from the obvious that
this code probably won't cleanly apply - but I haven't tried to be honest).

> > I think it is useful to have the ability to add rewriters at the end of
> > service composition.  In my opinion it is always good to have an escape
> > hatch, and this seems to fit the bill.  But I agree that it is not
> > an elegant solution, and I wouldn=E2=80=99t want to advocate using it.

> Right.  As discussed on IRC, one problem is ordering: if there are
> several users of this features for a given service, you can=E2=80=99t really
> tell what=E2=80=99s going to happen, unless the modifications happen to be
> commutable.

As for ordering, since I was using NixOS, I know a way they solve issue
like this. Your system config there is composed of many options that
you set to values. One option can be set multiple times, and if that
happens, there are two possibilities - either both have same priority
and the type is composable, then both values are used and it is
composed with a function (ie. if you have lines type and you add
two values, it will get merged with \n). If it is not composable,
and error is thrown. If both have different priorities, the higher
priority is used.

So using something like this for this case - finalization could accept
functions along with priorities - maybe a record?. If same priority is used,
(finalization1 (finalization2 original-config)) is used,
if not, the one with higher priority is used. Imo this would allow
for more use cases, even though of course it's not perfect - sometimes
options just aren't composable well.

This would solve an issue where if a service creator making a service
in a channel decides to use this feature, the end user can still easily
override the original finalization function, or deliberately
make their change composable, so both finalization procedures
can be called fine.

Regards,
Rutherther

Send a report that this bug log contains spam.

debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Tue Sep 9 07:58:36 2025; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.