From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 04:28:36 2021 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: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Liliana Marie Prikler Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) 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-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org, zimoun X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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.