From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 2NppH4xM7WK8yAAAbAwnHQ (envelope-from ) for ; Fri, 05 Aug 2022 18:59:56 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AMhyH4xM7WI4tgAA9RJhRA (envelope-from ) for ; Fri, 05 Aug 2022 18:59:56 +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 2F70A16AC2 for ; Fri, 5 Aug 2022 18:59:56 +0200 (CEST) Received: from localhost ([::1]:48540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oK0fz-00056I-AJ for larch@yhetil.org; Fri, 05 Aug 2022 12:59:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oK0fn-00056A-Pc for guix-devel@gnu.org; Fri, 05 Aug 2022 12:59:43 -0400 Received: from out2.migadu.com ([2001:41d0:2:aacc::]:31531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oK0fl-0007Q7-49 for guix-devel@gnu.org; Fri, 05 Aug 2022 12:59:43 -0400 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reproduciblemedia.com; s=key1; t=1659718777; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rHrwrUeozxsgBKmkccmTzJtzBtqQvJCdnxHicFJxvyE=; b=r806nshrOQzjl7RU2WnNf5M5C+K7uq0G7XcSCDlUDMvPb/kMA6mycFADqVuA20QQgzIPiP 2J37uPIr8HmaxzOmbTBZLdCo8iydfQjfMBcSbVNvZRjfOmDGM3j6UI3NLV9GAFbtlljmDs U6CaBnOlMmvANf59wBvl/bmBNd/ddLc= Date: Fri, 05 Aug 2022 16:59:36 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: blake@reproduciblemedia.com Message-ID: <5948e681e5939058f699c0aa8f4f7c52@reproduciblemedia.com> Subject: Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches. To: "Maxime Devos" , "Guix-devel" In-Reply-To: <98da36a2-d0cc-77da-77bf-6984253131ac@telenet.be> References: <98da36a2-d0cc-77da-77bf-6984253131ac@telenet.be> Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=blake@reproduciblemedia.com; helo=out2.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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=1659718796; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=rHrwrUeozxsgBKmkccmTzJtzBtqQvJCdnxHicFJxvyE=; b=aOtLpo9lHaWJZSL+WAFN3UlATIjyKuN9YRn2/ulznvubZOhEFTmT7tipEocJboxH8hxKW/ IMmLFUYBrOp7XR1oBlc6u6bU/TTIIPOFc6IoHL7503j8MHmitbDiXBDjDU4SE37YErcrff Klpz/Cd8BelTS51O74IMvzBVGmfj1KfmpgCLVsrMrDPb5kyC7CpvP5taDgDvPRlq/j6O1R wUwW3sn26GsCcUwJVOogvRhGVTSFt8oVWVRdk/z0VKNoWgKv+gt02SoBYI3s2Xnzh+1sr7 N2LDPilFDxm4DE82Ngnu+1Kfxy8EC9FVm2mxf4xWzGShjLrTBEPxVDlUZ1umnQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659718796; a=rsa-sha256; cv=none; b=gduaZIhpvV2i46QSdva+/va20nW4kXc9XXJnP8VXqDzdbUI9BZIzy+WWUtX0+tOPWDGFJj rjuLlCYV9Eq7P6hhYHbV7Zx3L7X7LYSu87WsxcJrn2OHIxk+TTR0NWcU39mWqAGjSS33JN KrtzbAs4x/ycitQ3SCsRYMSCeX97lx2bJrswYuVRYUUHQnHCM4df+lIjn5jnu/L1DEqV5T 5geuHUaUtM63z5HRGtkvRy3NtZZc3ULsddqaZJ5jCEUOOI99lf+vpO6CtXCx3dDmpSoY4I /UiqNLtuMTn4LMufD7ZWtAsz+O+LGQ7uca0bK6HoKG4q4hmxriLDlpXSe5YEFw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=reproduciblemedia.com header.s=key1 header.b=r806nshr; dmarc=pass (policy=quarantine) header.from=reproduciblemedia.com; 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: -5.90 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=reproduciblemedia.com header.s=key1 header.b=r806nshr; dmarc=pass (policy=quarantine) header.from=reproduciblemedia.com; 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: 2F70A16AC2 X-Spam-Score: -5.90 X-Migadu-Scanner: scn0.migadu.com X-TUID: yCFOZo4deVTN Hi Maxime,=0A=0AAdding some basic grammatical corrections below:=0A=0AAug= ust 5, 2022 1:59 PM, "Maxime Devos" wrote:=0A=0A= > Here's a v2. I've changed the structure to something close to what Juli= en proposed, it looks a lot=0A> better now to me!=0A> =0A> The (^) should= probably be tested before the final version.=0A> =0A> I don't think the = list of 'guiding principles' is worded well, probably needs more work.=0A= > =0A> [something I wrote previously]=0A> =0A> Feel free to try to separa= te the things, but going previous discussions, many tings are important,= =0A> and they appear all to be inseparable.=0A> Well seems like I was wro= ng, it splits nicely in three subsections!=0A>> I=E2=80=99d suggest start= ing with a patch against that section to address one=0A>> specific point = that you think is the most pressing one. From there we=0A>> can continue = the discussion.=0A> =0A> As written in another response, I don't really h= ave an opinion on what's more pressing than=0A> another. I have written t= hree 'points', but we don't have to discuss them all at once, maybe first= =0A> 20.4.5.2? That one sounds relatively simple to me.--- [start]=0A> = =0A> 20.4.5 Snippets, phases and patches.=0A> =0A> Snippets, phases and p= atches at times serve overlapping purposes. To decide between the three,= =0A> there are a few guiding principles:=0A> =0A> * In principle, Guix on= ly has free software; when the upstream source contains some non-free=0A>= software, it has to be removed such that =E2=80=98guix build --source=E2= =80=99 returns the "freed" source code=0A> rather than the unmodified ups= tream source (see: 28.4.1 Software Freedom).=0A=0ATechnical grammatical c= orrection: the software that Guix "has" is that in the monorepo,=0Abut it= "distributes" many packages. Thus:=0A--8<---------------cut here--------= -------start------------->8---=0A* In principle, Guix only distributes fr= ee software; when the upstream source contains some=0Anon-free software, = it should be removed such that =E2=80=98guix build --source=E2=80=99 retu= rns the "freed"=0Asource code rather than the unmodified upstream source = (see: 28.4.1 Software Freedom).=0A--8<---------------cut here------------= ---end--------------->8---=0A=0A> * The source of the package needs to co= rrespond to what is actually built (i.e., act as the=0A> corresponding so= urce), to fulfill our ethical and legal obligations.=0A=0AThe [i.e.] adde= ndum above is redundant, its better worded as:=0A--8<---------------cut h= ere---------------start------------->8---=0A* The source of a package mus= t correspond to what is actually built (i.e., there must be=0Aan explicit= relation between source code and the result of its build for all builds)= ,=0Ato fulfill our ethical and legal obligations.=0A--8<---------------cu= t here---------------end--------------->8---=0A=0A=0A> * It is convenient= for the source derived from an origin to build on any system that the up= stream=0A> package supports.=0A> * The source needs to actually work, not= only on your Guix system but also for other systems; this=0A> requires s= ome care for substitutions involving store items and other architecture-s= pecific changes.=0A> =0A> * Sometimes, there is more than one way to do i= t. Let's go for the simplest one. Sometimes, which=0A> tool is the simple= st, is subjective, that's fine too.=0A=0AI think would be more clearly wo= rded as:=0A--8<---------------cut here---------------start------------->8= ---=0A* When presented with a variety of strategies for defining a packag= e, choose whichever is simplest.=0ASometimes this is subjective, which is= also fine. What matters is that you prefer techniques that=0Aare common = within the community (i.e. patterns that appear throughout gnu/packages/.= ..) and=0Aare thus clearly legible for reviewers.=0A--8<---------------cu= t here---------------end--------------->8---=0A=0A=0A> To make things mor= e concrete and to resolve conflicts between the principles, a few cases h= ave been=0A> worked out:=0A=0ATo a newcomer (the target audience), the ab= ove may lead to confusion as to what wasn't already =0Aconcrete in the ab= ove descriptions, or what principles above come into conflict. There is a= mild,=0Alatent assumption that they are familiar with the Guix workflow,= which should be avoided. Thus I =0Asuggest:=0A--8<---------------cut her= e---------------start------------->8---=0AFor the purpose of clarifying p= referred practices and reducing friction in the review process=0Aintroduc= ed by subjective variation, a few guidelines have been worked out:=0A--8<= ---------------cut here---------------end--------------->8---=0A> =0A> 20= .4.5.1 Removing non-free software. Non-free software has to be removed in= a snippet; the reason is=0A> that a patch or phase will not work.=0A=0AW= ell, it might work on their machine, but not for community standards. To = reduce confusion:=0A--8<---------------cut here---------------start------= ------->8---=0A20.4.5.1 Removing non-free software.=0ANon-free software s= hould be removed using snippets; when removing non-free software, a patch= or phase=0Awill not be accepted.=0A--8<---------------cut here----------= -----end--------------->8---=0A=0A> =0A> For a patch, the problem is that= a patch removing a non-free file automatically contains the=0A> non-free= file (^), and we do not want anything non-free to appear in Guix even if= only in its=0A> patches.=0A> =0A=0AIs better as:=0A--8<---------------cu= t here---------------start------------->8---=0AFor patches, the issue is = that a patch that removes a non-free file automatically contains the=0Ano= n-free file (^), and we do not want any non-free software to be distribut= ed with Guix, even =0Aif it only appears within the context of a patch.= =0A=0AConcerning phases, the problem is that they do not influence the re= sult of =E2=80=98guix build --source=E2=80=99.=0A--8<---------------cut h= ere---------------end--------------->8---=0A=0A> 20.4.5.2 Removing bundle= d libraries.=0A> =0A> Bundled libraries should not be removed with a patc= h, because then the patch would contain the full=0A> bundled library, whi= ch can be large. They can be removed either in a snippet or a phase, ofte= n=0A> using the procedure 'delete-file-recursively'. There are a few bene= fits for snippets here:=0A> =0A> When using snippets, the bundled library= does not occur in the source returned by =E2=80=98guix build=0A> --sourc= e=E2=80=99, so users and reviewers do not have to worry about whether the= bundled library contains=0A> malware, whether it is non-free, if it cont= ains pre-compiled binaries ... There are also less=0A> licensing concerns= : if the bundled libraries are removed, it becomes less likely that the l= icensing=0A> conditions apply to people sharing the source returned by = =E2=80=98guix build --source=E2=80=99, especially if the=0A> bundled libr= ary is not actually used on Guix systems. (*)=0A> =0A> As such, snippets = are recommended here.=0A> =0A> (*) This is _not_ a claim that you can sim= ply ignore the licenses of libraries when they are=0A> unbundled and repl= aced by Guix packages -- there are less concerns, not none.=0A> =0A> 20.4= .5.3 Fixing technical issues (compilation errors, test failures, other bu= gs ...)=0A> =0A> Usually, a bug fix comes in the form of a patch copied f= rom upstream or another distribution. In=0A> that case, simply adding the= patch to the 'patches' field is the most convenient and usually does=0A>= not cause any problems; there is no need to rewrite it as a snippet or a= phase.=0A> =0A> If no ready-made patch already exists, then choosing bet= ween a patch or a snippet is a matter of=0A> convenience. However, there = are two things to keep in mind:=0A> =0A> First, when the fix is not Guix-= specific, it is strongly desired to upstream the fix to avoid the=0A> add= itional maintenance cost to Guix. As upstreams cannot accept a snippet, w= riting a patch can be a=0A> more efficient use of time. Secondly, if the = fix of a technical issue embeds a store file name,=0A> then it has to be = a phase. Otherwise, if a store file name was embedded in the source, the = result=0A> of 'guix build --source' would be unusable on non-Guix systems= and likely also unusable on Guix=0A> systems of another architecture.=0A= =0AAnd some basic last corrections here:=0A--8<---------------cut here---= ------------start------------->8---=0AFirst, when the fix is not Guix-spe= cific, it is strongly desired by upstream that the fix avoids any=0Aaddit= ional maintenance costs for Guix. As upstream cannot accept a snippet, wr= iting a patch can be a=0Amore efficient use of time. Secondly, if the fix= of a technical=20issue embeds a store file name,=0Athen it has to be a p= hase. Otherwise, if the store file name were to be embedded in the source= , the=0Aresult of 'guix build --source' would be unusable on non-Guix sys= tems, and also likely unusable on=0AGuix systems of another architecture.= =0A--8<---------------cut here---------------end--------------->8---