From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OHiqEwiJ62KwSAAAbAwnHQ (envelope-from ) for ; Thu, 04 Aug 2022 10:53:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id SBRZEwiJ62KhnQAAauVa8A (envelope-from ) for ; Thu, 04 Aug 2022 10:53:28 +0200 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 09F813D312 for ; Thu, 4 Aug 2022 10:53:28 +0200 (CEST) Received: from localhost ([::1]:35600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJWbf-0002E2-6z for larch@yhetil.org; Thu, 04 Aug 2022 04:53:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJWZr-00019L-Jm for guix-devel@gnu.org; Thu, 04 Aug 2022 04:51:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36712) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJWZq-0008OY-ED; Thu, 04 Aug 2022 04:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=HqLJKmpNMArCaFxkkSSN+oXRTubyjUAC4kXtbBEzui8=; b=dxj9fzDlrpmghCb+e3Zj u7aYKHJhcJ2jzKPlPv39YNlo1RFxzenZsO8fI7tpJufEJpfZtEjGWO5m85o0Pq0I3z1UH21s0kocd bHnN0Z5n7u7HZTar5OLqwxFS/9oOI97wubf9c0v5IaTBql0o4SUFhOEkUtIbtqAjceWUtA4AVPDw7 OwLu49tZKihB2Y955mARHp0d20iLgh77gnDbfiUcgrWpEWm62MQZnO6vJFVrMeuqaP/ZonE08jT4w Mgw3koEUvBs9y3kfvrpwYR8nZZfm2KW5ooBcpotSxrZDnuBZD+ytJ4Fp70o+d/xYHbSXczMF7eeOF f9GXmh9azYpVFw==; Received: from [193.50.110.201] (port=57196 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJWZp-00025i-Ei; Thu, 04 Aug 2022 04:51:34 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxime Devos Cc: Guix-devel Subject: Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches. References: X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Septidi 17 Thermidor an 230 de la =?utf-8?Q?R=C3=A9v?= =?utf-8?Q?olution=2C?= jour du Lin 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: Thu, 04 Aug 2022 10:51:31 +0200 In-Reply-To: (Maxime Devos's message of "Mon, 25 Jul 2022 05:17:33 +0200") Message-ID: <87h72spf1o.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (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.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1659603208; 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:dkim-signature; bh=HqLJKmpNMArCaFxkkSSN+oXRTubyjUAC4kXtbBEzui8=; b=mYKvJD/lLeMlvDyWH+LSZG71JND3Xz9V9mH0Rlli+1EtTCjNXktwWkANZlCwyogv/k6m0P v9fGnbwmDJYsL32wohChs8s6lZBHw+Eed4DNgM7793UiE+mWdXMUJpE5Q/jBqdNQnovW56 Wk5zdb0iXRYPhQ6ivBizQ44r1TEQz9Q9J0Kt1O8fg27a25UZuKR1wouDkpxyCtvvtwfIB7 obkVB8WOJQFID5dGM0x5DL+lWcWiGQCLdZ1EoerXhds+wlmEfvWcsvcvWFUafFK8bj+SaQ 0bHzIkT5FN0hfgT8Sc+ePGm4DRvmZDMEMKU+I/O/WhAeB66+8q5hFKC3RiEb4w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659603208; a=rsa-sha256; cv=none; b=NQfIbIx7yY4wlBs46tfbd0LbT4c0Ax6TRxvYDkbXyD4SOR8zrrpYuvVnPts9JTfbsNI/vg cUGi874WgZkTFWfl2TiB9PeQ9cMD5vAz779kHWbWZ16AodrQMoOvdvuQKN2Og3oIpzk+3A BkIToGqsa0FKijAJtbMz4FjkrYe7R2btBeR3Jx0lGY5RNBHfXkwVY6uIFiCQuNeDoTEgwP YD6AgA2x/VOi6yA3ZmVB1fL1hAivp8VWCxB5KMgpYHLn9ks+H4m9ItMUmfSx0Ok4hj7Cue bsrFJtBCU5OBr3CS3ydAR/C0Wxg3Ye66vXYmqnX14qhYV6yunvX9H0jszBmJIw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=dxj9fzDl; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -7.91 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=dxj9fzDl; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 09F813D312 X-Spam-Score: -7.91 X-Migadu-Scanner: scn0.migadu.com X-TUID: VSKykihmi/Ed Hello! Maxime Devos skribis: > Context: it's currently a mess:, and at times contradictory As a rule of thumb, I=E2=80=99d suggest avoiding denigrating wording like t= his, in an effort to keep communication smooth and effective. > * There is policy involving those three, as can be seen from the > shepherd mess. What is =E2=80=9Cthe shepherd mess=E2=80=9D? Realize also that not everyon= e may agree that there is =E2=80=9Ca mess=E2=80=9D in the first place. The =E2=80=98shepherd=E2=80=99 package uses a snippet to fix a bug. I thin= k that=E2=80=99s akin to applying a patch: the intent is that =E2=80=98guix build -S=E2=80=99 giv= es you the code that=E2=80=99s actually built, with patches applied. > * This policy is partially secret, as can be seen by some people > treating some things as policy even if it's not in the manual. There=E2=80=99s no secret, but there might be unwritten rules. I think what we need to do is improve the =E2=80=9CSnippets=E2=80=9D sectio= n of the manual, as you propose, so we don=E2=80=99t have unwritten rules and misunderstandings based on hearsay. [...] > 20.4.5 Snippets, phases and patches > > Snippets, phases and patches at times serve overlapping purposes. To > decide between the three, there are several considerations to keep in > mind: > > * Patches must not be used to remove non-free files, because a patch > by construction contains the non-free file itself so the patch would > be non-free, which would not be acceptable to Guix. Likewise, > patches should not be used to remove bundled libraries, to avoid > large space usage, but this is not an absolute rule unlike as for > non-free files. > * Snippets are often convenient for removing unwanted files such as > bundled libraries, non-free sources and binaries. It is technically > also possible to use phases for this, albeit slightly less > convenient at times. However, phases must not be used to remove > non-free sources, as then the output of "guix build --source" would > still contain the non-free sources, which is incompatible with Guix' > stance on free software. Likewise, phases should not be used to > remove binaries; however, this is not strictly forbidden. > * Snippets must not embed store items in the source, as this is > incompatible with cross-compilation and prevents effectively sharing > the source code produced with "guix build --source" with people > using non-Guix systems. > * In principle, you can apply a patch from a phase. However, this > causes the result of "guix build --source" to not correspond to the > actual source code anymore (i.e., it doesn't act as corresponding > source anymore), so consider this a last resort for situations such > as avoiding causing a world-rebuild for a patch fixing a > target-specific bug by making the patching conditional upon > target-foo?. If you apply a patch from a phase, make sure that the > patch appears in the inputs or native-inputs, such that "guix build > --source=3Dall" will include the patch. > > @c this relaxes the old rule a little > > * Ideally, the source derived from the origin should be usable for > building on any system that the upstream package supports (even if > Guix does not support that system), as a courtesy to the people that > the source code is shared with. However, this is not an absolute > rule, most important is that it is usable on Guix and it is allowed > to neglect this recommendation when it is tricky to follow or a > large amount of work. For example, if some Windows-specific source > files are non-free, you can simply remove them without replacing > them by a free implementation, even if that would reduce the set of > systems the package can be built on. > > Sometimes, there remains more than one acceptable way to accomplish > the goal. In that case, choose whatever appears to be most convenient. I kinda agree with what Julien wrote. I=E2=80=99d suggest starting with a patch against that section to address o= ne specific point that you think is the most pressing one. From there we can continue the discussion. WDYT? Thanks, Ludo=E2=80=99.