From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Why is "append" the activation service's "compose" procedure? Date: Thu, 29 Mar 2018 09:32:19 +0200 Message-ID: <878tabs5fg.fsf@gmail.com> References: <87muyzdrjq.fsf@gmail.com> <87zi2vdm6r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1S2t-0000F6-Ae for guix-devel@gnu.org; Thu, 29 Mar 2018 03:32:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1S2s-0002O1-Be for guix-devel@gnu.org; Thu, 29 Mar 2018 03:32:27 -0400 In-Reply-To: <87zi2vdm6r.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 26 Mar 2018 15:02:36 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Chris Marusich skribis: > >> The fold-services procedure always applies the "compose" procedure to a >> single list. So why does the activation-service-type use the append >> procedure as its "compose" procedure? Wouldn't it more accurately >> reflect our intent if we used the identity procedure instead? > > Yes, you=E2=80=99re right here as well. :-) > > =E2=80=98boot-service-type=E2=80=99 has the same problem. > > Can you fix both? I've done this in commit 7874e9e047219cce5ae339e57cd76f158bc19f63. By the way, I noticed that the cups-service-type also uses "append" as its "compose" procedure. I think this is suspicious. The comment in the code says: ;; Extensions consist of lists of packages (representing CUPS ;; drivers, etc) that we just concatenate. (compose append) However, that doesn't seem to be what's going on in the "extend" procedure that follows it: ;; Add extension packages by augmenting the cups-configuration ;; 'extensions' field. (extend (lambda (config extensions) (cond ((cups-configuration? config) (cups-configuration (inherit config) (extensions (append (cups-configuration-extensions config) extensions)))) (else (opaque-cups-configuration (inherit config) (extensions (append (opaque-cups-configuration-extensions config) extensions))))))) Since there are no examples of extensions of the cups-service-type in the Guix source tree, I'm not really sure what the intended behavior is. If the "compute" procedure of any object that extends the cups-service-type is intended to return a single package, then my guess is that the "compose" procedure above should really be identity, not append, in order to more accurately reveal the intent. However, if the "compute" procedure is intended to return a list of packages, then my guess is that the cups-service-type may not be functioning as intended, and to fix it we will need to change the "compose" procedure to concatenate. Can someone who is familiar with the cups-service-type clarify what the "compute" procedure of an extension of the cups-service-type is actually supposed to return? I've CC'd Andy, who originally added the cups-service-type, in the hope that he might respond. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlq8loQACgkQ3UCaFdgi Rp1dBhAAzP7CubsjY+FyYglHv3dOZykCoygNkKFUEHopxSLvzFeJfOSYzazynYE5 EH1WY9CPkfVOW2S41ktfQJa0KQhfxIBfbhf92tByydMlUE+/tIszg8mj0jf7cS74 0B7Fx3zLPcY+9HncXqsfkhzu6flN3ijtnh/NiWYCchWqnZrIZZ4iKczlxI7dIzhv O2S719yEugh6Qc5p7JWkF3FUnoXv8RQ5jhvybE9O6Vpm7J/FnMySQkJnTyxV3cqG fc8ShcDGWtwxjAq+ln5bHkF10BnJ3nASdbqM+1XxTqXE16KLQVHG9pLHibnE6Gvo AvjjX0zrpLA1ATljZgtr3+ftHvvsWCq1Yd/Uax9uOK0FE2sfaX5w/WOLqTvYhVu2 xEWrRcrJVhI/3blKJ2/jw0CSkBX16hL+x9bmQwdyFCYqKcosHXy1HkIGndb7i0GC 8BQPCsmaGdzflDR30067vVpfPhCi3kpWpEyG4lmEBNQb/KCB/5E5U9u67n4K2h3T HqpzQ6pb4Tow+x4DBAT+IrV/GtqQ5VY+rHzL0TkqqYKbjqw+c1iv6Z7nVc0H9VWQ TPerhwWWswiAx7Vytg1dIYM+Zm0LALIRvlP/90fKl/js0BacVdqu5Vd78O+O1xU1 XTQ/NB4a9RuShiQX+lAi4AmiRMWTwo2Zn8UJVLoqMvlPKY45b+0= =DT+N -----END PGP SIGNATURE----- --=-=-=--