From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id eBeON1d1VWGFNgEAgWs5BA (envelope-from ) for ; Thu, 30 Sep 2021 10:29:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id cAceM1d1VWFDagAAbx9fmQ (envelope-from ) for ; Thu, 30 Sep 2021 08:29:11 +0000 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 483EF1AB1C for ; Thu, 30 Sep 2021 10:29:11 +0200 (CEST) Received: from localhost ([::1]:44322 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVrRF-0001Sl-QG for larch@yhetil.org; Thu, 30 Sep 2021 04:29:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVrR8-0001Sd-Fj for guix-patches@gnu.org; Thu, 30 Sep 2021 04:29:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:39864) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mVrR8-00064u-7e for guix-patches@gnu.org; Thu, 30 Sep 2021 04:29:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mVrR7-0006H3-Og for guix-patches@gnu.org; Thu, 30 Sep 2021 04:29:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 30 Sep 2021 08:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50620 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler Cc: Mark H Weaver , 50620@debbugs.gnu.org, zimoun Received: via spool by 50620-submit@debbugs.gnu.org id=B50620.163299051624082 (code B ref 50620); Thu, 30 Sep 2021 08:29:01 +0000 Received: (at 50620) by debbugs.gnu.org; 30 Sep 2021 08:28:36 +0000 Received: from localhost ([127.0.0.1]:51410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVrQh-0006GM-Rj for submit@debbugs.gnu.org; Thu, 30 Sep 2021 04:28:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVrQe-0006G8-5K for 50620@debbugs.gnu.org; Thu, 30 Sep 2021 04:28:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36106) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVrQY-0005aW-CI; Thu, 30 Sep 2021 04:28:26 -0400 Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=60502 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVrQY-000393-2D; Thu, 30 Sep 2021 04:28:26 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <87a6jv8qu7.fsf_-_@gnu.org> <87pmsr5a0z.fsf_-_@gnu.org> <09c009ec61b8f9c1746f98916f492b8953b16dcc.camel@gmail.com> Date: Thu, 30 Sep 2021 10:28:24 +0200 In-Reply-To: <09c009ec61b8f9c1746f98916f492b8953b16dcc.camel@gmail.com> (Liliana Marie Prikler's message of "Thu, 30 Sep 2021 01:44:37 +0200") Message-ID: <87r1d64gd3.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1632990551; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=FOqNjbygXKchasbAZiY9+x+80XkkQX9XYPrddi59Ltw=; b=BC56aMl7Sb4aQFKwkSu6KbbPVvqrgdH0oNT2HdUWStKP6nXwzywRo32oWXspKPyi0HJqGw 6DNxvIHjY8ouUPeAWxlzByH7AwkVIYkeBxWUfkpAkfO//DLkC+CesRyi6W44w4w30XgPmr H+/WF5TOVsZhNQsddjEAraHa9ObicyHJZKduSvZm2jvVrAFH3JW6TORZsKzV2dPRb+4B/g VhXN+oVCiHQEddJLvRZ5q75R5CmEo/7x0xwUvlxZ7w3wH/8hlCPWTkMCBL3Ie+xHOM1J5s 3WGg64CisIFo0FjXrrJDJ+8duTev26NignZS6XaCCAck/hWdEgQnA/E7S5e1gg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632990551; a=rsa-sha256; cv=none; b=efCuC9OSEGMGdBXLa3RX9UvR8J3SLq5Ux9CCQPowHf/WWH65/qyBmzq6tlnwT+5fMPIdB6 xzY6vB9WDaJWNkBiezbIxCMJ7n47ZvPPYUJLiFCNCuOya2i0t10XRQ79KNQgzdNdO2nKj2 NNU6P9Us+z3cVAUy5GPd3iCBWH9u2kDVAb0gbvl169JWSP6atg0eHhfAOv0p7KC139BQSw fvRLAzHi4AHQ3eF2/4sKmD/PGZBlfh8fnGU/JXPd9EJxUjVvMSP5AD+Hm2bwijfVHwgV0b +dACPogTfQH+WJMvnaA9fVmvZ3rjCiTry/sT63y/OZ0aTwnhm5rz9Xe4sE6Ggg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.40 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 483EF1AB1C X-Spam-Score: -1.40 X-Migadu-Scanner: scn0.migadu.com X-TUID: Y2BUsZT9KRuM Hi! Liliana Marie Prikler skribis: > I think asking users to supply their own implementation of a 200 line > long function to be a bit much to only do part of the job. On the > other hand, the promise for linux-libre takes 400 lines and for icecat > more than 600, but I think there are some things we ought to factor > out. Particularly, looking up tools like tar or gzip and even the > actual packing are always the same. True, there=E2=80=99s a lot going on there, though that=E2=80=99s partly be= cause it=E2=80=99s generic. > What we can't currently control is the top directory name and the > output name. Both of that could be customized by supplying a "repack- > name" field, which is used as basis for the directory name and the > tarball name. > Another thing we can't easily control are extraneous inputs to the > patches, although the patch-inputs field *does* exist. It=E2=80=99s possible to use a gexp as the snippet, where you can refer to additional things in there (though in practice this is currently impractical due to snippets not being thunks/promises.) >> > A combination of the above might make computed origins obsolete for >> > good, but the question remains whether that is a better >> > design. What do y'all think? >>=20 >> The design goal is to have clearly identified types: , >> , . For each of these, we want some >> flexibility: build system, origin method, etc. However, beyond some >> level of stretching, it may be clearer to just use the catch-all >> =E2=80=98computed-file=E2=80=99 or to devise a new type. After all, tha= t=E2=80=99s how >> came to be (we could have used instead with a >> suitable build system). >>=20 >> There=E2=80=99s a tension between =E2=80=9Cpurely declarative=E2=80=9D a= nd =E2=80=9Cflexible=E2=80=9D, and >> it=E2=80=99s about striking a balance, subjectively. > To be fair, I did think that "computed-tarball" might be a good > abstraction in some sense, but on another hand origins are computed > tarballs with a record interface. > > On a somewhat related note, origins have this weird situation going on > where some things like git or svn checkouts need to be defined through > them, whereas others may pass unhindered. I feel that this contributes > to the equation of source =3D origin, that might have caused "computed- > origin-method" to exist in the first place. I=E2=80=99m not sure what you mean by =E2=80=9Cothers may pass unhindered= =E2=80=9D? You mean other VCS checkouts? > What do you think? I think the situation of IceCat and Linux-libre is unusual: 2 packages out of 18K. That probably explains why we have a hard time figuring out how to generalize the issues that =E2=80=98computed-origin-method=E2=80=99 = addresses. What you propose (IIUC) sounds interesting: we=E2=80=99d provide a data type, which would make the source URL manifest (something that=E2=80=99s useful for , f= or instance), but the lowering step would be entirely custom, similar to what it already looks like: (define-record-type* computed-tarball make-computed-ta= rball computed-tarball? this-computed-tarball (url computed-tarball-url) ;or could be an (builder computer-tarball-builder (thunked)) ;gexp (location computed-tarball-location (innate) (default (current-source-l= ocation)))) Is this what you had in mind? Thanks, Ludo=E2=80=99.