From unknown Sat Sep 20 08:59:29 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#50620 <50620@debbugs.gnu.org> To: bug#50620 <50620@debbugs.gnu.org> Subject: Status: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) Reply-To: bug#50620 <50620@debbugs.gnu.org> Date: Sat, 20 Sep 2025 15:59:29 +0000 retitle 50620 [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) reassign 50620 guix-patches submitter 50620 zimoun severity 50620 normal tag 50620 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 07:45:18 2021 Received: (at submit) by debbugs.gnu.org; 16 Sep 2021 11:45:18 +0000 Received: from localhost ([127.0.0.1]:53982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQppO-0007Ig-Cz for submit@debbugs.gnu.org; Thu, 16 Sep 2021 07:45:18 -0400 Received: from lists.gnu.org ([209.51.188.17]:54188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQppM-0007IW-LT for submit@debbugs.gnu.org; Thu, 16 Sep 2021 07:45:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQppM-0001cl-DX for guix-patches@gnu.org; Thu, 16 Sep 2021 07:45:16 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:46643) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQppK-0003FM-Px for guix-patches@gnu.org; Thu, 16 Sep 2021 07:45:16 -0400 Received: by mail-wr1-x42a.google.com with SMTP id x6so8943796wrv.13 for ; Thu, 16 Sep 2021 04:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=LS63QokjZ0Eee4pngs9yH3+sZ+7biwhUbKcojMjMmZ0=; b=eaNwkaSoz7GFE0RveokZ6sVDcuePLjLS0r1iRB4aGY4rWLWs+rljiFwWceQBiezWeX Wf2eIPxGr9d7NraNAIUNmbG1VfyYnD9Or8ftJFEF2NBYWAMOxphUn4VQle9AYhbNbDUA EGwtPKCqQoib7RGfcmm8wOoamnVc6wN2KFn2fiTjMCtNGipWBKT/oG9mYllheWBMBoo4 8iewQX/Q3vSSMhEPavmUxGR/IzwjGhiHi2Od+i5p6QbQbiVT1A27qK6ZMemMtvqklYJq WGFC41cz9DlqvE5XsMFOu9OB7Wlft43tery5faPJhzs4/oBvQdpb776mI+ubm1LPy2Dg dPEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=LS63QokjZ0Eee4pngs9yH3+sZ+7biwhUbKcojMjMmZ0=; b=24BW+rcRrJJPAGNnDPY3E1969Vkrz4TJiEuzfFkfrW948A6aex7VdyqRKey8h3aTeH YOx/kIb6DKWfHVft2xvqfKNSuSYcen24UIxC8ddTuBHTS0S8oHiv374HLToMZJUFhMDH cF3wpeQ84XqWdvncdKqraiHdLPRT4WlrfQQBTD7VJPZTtKJ3Uh0Z/uMx47rJpCUTqT6R 2BD0QlvdoZInm42SYVfHJGNxb8y+rDT1gGpdSI5BFZNl0BO/I568aU2NVNCNUlUGpC/k um5YW3LPIM5brsPqbFw7k5xdMOjdRk5LKSTkRpBbthD3qeUx05cMsyLZhtQwrD65P8ti mstA== X-Gm-Message-State: AOAM532VScFySZ8L8EaR1oaoJ83mZ0pTxVMGnYS3MDKmf8X0cu4f2jyI qo1hrXGr67KdP/k+TKZOgFdbNot3oK0= X-Google-Smtp-Source: ABdhPJyby3L5/g0bskdaq/sIhqJZA4XqTLGmTxcKPhnSEk1ryY6Z9zOIh6AJ4c0wEk//uV7VLkNjgg== X-Received: by 2002:adf:e546:: with SMTP id z6mr5621365wrm.346.1631792712101; Thu, 16 Sep 2021 04:45:12 -0700 (PDT) Received: from localhost.localdomain ([193.48.40.117]) by smtp.gmail.com with ESMTPSA id j27sm2591389wms.6.2021.09.16.04.45.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 04:45:11 -0700 (PDT) From: zimoun To: guix-patches@gnu.org Subject: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) Date: Thu, 16 Sep 2021 13:45:05 +0200 Message-Id: <20210916114505.2686370-1-zimon.toutoune@gmail.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 X-Debbugs-CC: mhw@netris.org Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: 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: -2.3 (--) Hi, This patch follows the discussion from [0]. In short, it simplifies the code generating the file 'sources.json' used by Software Heritage to ingest all the tarballs. It would partially fix the issue raised here [1]. The first patch moves the duplicate of 'computed-origin-method' and adds comments. Please proof-read. :-) The second patch update the package guix. Since I cannot know the commit hash and checksum beforehand, it is set to xxxx and should be updated by the commiter. This update is necessary to get the correct Guix-as-library used by the website generator of 'sources.json', IIUC. All the best, simon 0: 1: zimoun (2): guix: packages: Document 'computed-origin-method'. gnu: guix: Update to xxxx. gnu/packages/gnuzilla.scm | 14 ++------------ gnu/packages/linux.scm | 14 ++------------ gnu/packages/package-management.scm | 6 +++--- guix/packages.scm | 23 ++++++++++++++++++++++- 4 files changed, 29 insertions(+), 28 deletions(-) base-commit: 33bc3fb2a5f30a6e21f1b8d6d43867d921bd951c -- 2.32.0 From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 07:47:44 2021 Received: (at 50620) by debbugs.gnu.org; 16 Sep 2021 11:47:44 +0000 Received: from localhost ([127.0.0.1]:54001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQprk-0007Oa-Hg for submit@debbugs.gnu.org; Thu, 16 Sep 2021 07:47:44 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:55974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQprj-0007OJ-3k for 50620@debbugs.gnu.org; Thu, 16 Sep 2021 07:47:43 -0400 Received: by mail-wm1-f45.google.com with SMTP id 70so1666321wme.5 for <50620@debbugs.gnu.org>; Thu, 16 Sep 2021 04:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=B87dYz7oUEC4rXYidENqRvmdES+avudmEtXCGoOeaYA=; b=lFfOSxhv49AjvshGhaPqEtT1kuYftjmpmBIH2S3iYn60xltyDFPHuxQPZOB/B1Sv4m qxFRn4F6LFf3W/i4uZZ7x2GqLuYUqYZbtMkfWVtsdc0+H59ClmFXgCTc9oIxQYEOBaii kEBQjmcV9L5y+XKGGWgDHTcG4JvopNygJF3Ln0SLK8hLyNpzzi3D9kJVtJsanKW/sQjZ gUGKU2F0kay0UZszel2ezc9oTM2ToWCwg/EXpaXQxTrTYAuG80mjHCP+SU5q4tpcf+2Z KHXTO9qPBWks9sodrVnGPW+PdIg0G22khmgbqgkLH52gMPdYkQi5NtgEofsciAIfE06l B93Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=B87dYz7oUEC4rXYidENqRvmdES+avudmEtXCGoOeaYA=; b=u/R6iTuhBJIdEISfK7OEMFCBb+omsC9X0uezVD7UwAvF+AYlII2zr/X81v9uLCYusX 0DizqVfe/2+aDhoJpfrQZ/saLzvI7ELaYBXqRnHOfN9DIuthdodkpDo1cjKjz51ZtInH wLDJwaSDGMaVQ+Jysi5ftvhUDkW5rjba6+1KxMLVP3c65stJp7g4zGhrM28AgHiTpUcc HGytDk3xvTC2Tm33FDKcqIIg2ApTuWqeU8ogofNMfs5BjV+VC744j0vo8sB017jY5YYa Urh+W7WYzKLun5nn7P5TUzGNhil0UIhMSy2c34Qb14djFmkqLvf6UPrFwbEjp3dfKFMN c/4w== X-Gm-Message-State: AOAM530Pax2vEdZqbz9nBqVHTlPhtcXCd0D7LtPWwoNhTtRHnW7ytuXO WSWdbn8+Iep9D5ilTzTgCWzQXA4J3R8= X-Google-Smtp-Source: ABdhPJwtjgR/sTOrM6ARG2FHKsY78YyzwsTWiFRksDXmE/FwTyUbKwNJPGmBddLB4MuFxC2BNSAnPw== X-Received: by 2002:a1c:3b87:: with SMTP id i129mr708805wma.115.1631792857474; Thu, 16 Sep 2021 04:47:37 -0700 (PDT) Received: from localhost.localdomain ([193.48.40.117]) by smtp.gmail.com with ESMTPSA id l10sm3472519wrg.50.2021.09.16.04.47.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 04:47:37 -0700 (PDT) From: zimoun To: 50620@debbugs.gnu.org Subject: [PATCH 2/2] gnu: guix: Update to xxxx. Date: Thu, 16 Sep 2021 13:47:34 +0200 Message-Id: <20210916114734.2686426-2-zimon.toutoune@gmail.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210916114734.2686426-1-zimon.toutoune@gmail.com> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 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: -1.0 (-) * gnu/packages/package-management.scm (guix): Update to xxxx. --- gnu/packages/package-management.scm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm index 2611951a52..458e121ef2 100644 --- a/gnu/packages/package-management.scm +++ b/gnu/packages/package-management.scm @@ -137,8 +137,8 @@ ;; Note: the 'update-guix-package.scm' script expects this definition to ;; start precisely like this. (let ((version "1.3.0") - (commit "6243ad3812f8c689599a19f0e8b9719ba14461f2") - (revision 5)) + (commit "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx") + (revision 6)) (package (name "guix") @@ -154,7 +154,7 @@ (commit commit))) (sha256 (base32 - "0i3sgk2w2yjy9ip47vk0h17afk16yl5ih3p3q75083kgjzyjdm3d")) + "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")) (file-name (string-append "guix-" version "-checkout")))) (build-system gnu-build-system) (arguments -- 2.32.0 From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 07:47:47 2021 Received: (at 50620) by debbugs.gnu.org; 16 Sep 2021 11:47:47 +0000 Received: from localhost ([127.0.0.1]:54003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQprm-0007Oo-OX for submit@debbugs.gnu.org; Thu, 16 Sep 2021 07:47:47 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:37816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQpri-0007OI-QE for 50620@debbugs.gnu.org; Thu, 16 Sep 2021 07:47:44 -0400 Received: by mail-wm1-f45.google.com with SMTP id c8-20020a7bc008000000b002e6e462e95fso7155170wmb.2 for <50620@debbugs.gnu.org>; Thu, 16 Sep 2021 04:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=4IIHHqUhQKQN7CyJDFPM1+vkRqsNFbDxZrpo08ThJoE=; b=gzVAoT5CiOeWP08FXganZmDXcKbjS49S6I5IuX8ZswUghsPjR3s2fcSl7IZp6savip CQ03CcJnbOFh/Z079rIG+7fBIp2tJWtb76VCvNpfbUy7HsCTLMdNjzPpLKEnrJQEGKWH 9uW4JufNEKWl27seR3N+07NDkCCfppNwZSpaM+/Z/h5RqeIVMw5P8+Hoj67P6+5CtKSX OxB1wj3pN1vFh16MQ6h7Nf1r8QKdmgMNCGHVKBaJpJFUYryecxuJgb/JlFCJKJQJUxoa 9mS6LRfQIFaQbIoyYIAjHzJuAK1OG/As1LP/oXAtKLiQlU9/G5r/51g8hSKKz2baA/Mv Zn1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=4IIHHqUhQKQN7CyJDFPM1+vkRqsNFbDxZrpo08ThJoE=; b=MIekmaO2gi76OToJVMAqxXOl8NCi95e16Gw78FfgCkgYjav0M28qw7T5R46uU2JfQ5 Lb8nrCxaxgb0wT4mWYr0+nM4aXVTiZ00tWCMZtVRhULhiFoudKfJKH///XtK1nVx6vTb yBNa8QMTgTHT652DNZBUTaia884P1VyNIgbqWHmRD3BMFEWT19BYSEt6d+5W+XifDiZX x5jRtcB5zDZaCWygafK/td63dhuyaN2xEC+Q7wdZLMp/pIWCS78xwh4C3sS33dTpB4Jj qmlkCjAMlFE4oeJBmqcu9qHJ7om1kIXN3qB9Hy7qflZX5zdsGcSEdU1SpCJqk8DxTrYf NrpA== X-Gm-Message-State: AOAM532OTPhZnpVfSZFNe4fg82IQuD3eNnqGAaKGgwdap45wUAzqSyK+ DNgwD5lwHYDKMtSfhfK2Er2RRfd9cCA= X-Google-Smtp-Source: ABdhPJx3nocB7am6mLjPKs5wMZ5ucb+6XXdGfqI7ejdaqa5BELSOsqukNYpXBF+qJG0yjJclNOuDFQ== X-Received: by 2002:a1c:2b04:: with SMTP id r4mr9535074wmr.89.1631792856995; Thu, 16 Sep 2021 04:47:36 -0700 (PDT) Received: from localhost.localdomain ([193.48.40.117]) by smtp.gmail.com with ESMTPSA id l10sm3472519wrg.50.2021.09.16.04.47.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 04:47:36 -0700 (PDT) From: zimoun To: 50620@debbugs.gnu.org Subject: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. Date: Thu, 16 Sep 2021 13:47:33 +0200 Message-Id: <20210916114734.2686426-1-zimon.toutoune@gmail.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 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: -1.0 (-) The 'computed-origin-method' had been introduced as a workaround limitations in the 'snippet' mechanism. The procedure is duplicated which makes hard to automatically detects packages using it. * guix/packages.scm (computed-origin-method): Move procedure from... * gnu/packages/gnuzilla.scm: ...here and... * gnu/packages/gnuzilla.scm: ...there. --- gnu/packages/gnuzilla.scm | 14 ++------------ gnu/packages/linux.scm | 14 ++------------ guix/packages.scm | 23 ++++++++++++++++++++++- 3 files changed, 26 insertions(+), 25 deletions(-) diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm index 431b487fd0..9f6e1f24e1 100644 --- a/gnu/packages/gnuzilla.scm +++ b/gnu/packages/gnuzilla.scm @@ -682,18 +682,8 @@ in C/C++.") ("1j6l66v1xw27z8w78mpsnmqgv8m277mf4r0hgqcrb4zx7xc2vqyy" "527e5e090608" "zh-CN") ("1frwx35klpyz3sdwrkz7945ivb2dwaawhhyfnz4092h9hn7rc4ky" "6cd366ad2947" "zh-TW"))) -(define* (computed-origin-method gexp-promise hash-algo hash - #:optional (name "source") - #:key (system (%current-system)) - (guile (default-guile))) - "Return a derivation that executes the G-expression that results -from forcing GEXP-PROMISE." - (mlet %store-monad ((guile (package->derivation guile system))) - (gexp->derivation (or name "computed-origin") - (force gexp-promise) - #:graft? #f ;nothing to graft - #:system system - #:guile-for-build guile))) +;; XXXX: Workaround 'snippet' limitations. +(define computed-origin-method (@@ (guix packages) computed-origin-method)) (define %icecat-version "78.14.0-guix0-preview1") (define %icecat-build-id "20210907000000") ;must be of the form YYYYMMDDhhmmss diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index 285eb132f4..eb792be9a3 100644 --- a/gnu/packages/linux.scm +++ b/gnu/packages/linux.scm @@ -216,18 +216,8 @@ defconfig. Return the appropriate make target if applicable, otherwise return (file-name (string-append "linux-libre-deblob-check-" version "-" gnu-revision)) (sha256 deblob-check-hash)))) -(define* (computed-origin-method gexp-promise hash-algo hash - #:optional (name "source") - #:key (system (%current-system)) - (guile (default-guile))) - "Return a derivation that executes the G-expression that results -from forcing GEXP-PROMISE." - (mlet %store-monad ((guile (package->derivation guile system))) - (gexp->derivation (or name "computed-origin") - (force gexp-promise) - #:graft? #f ;nothing to graft - #:system system - #:guile-for-build guile))) +;; XXXX: Workaround 'snippet' limitations +(define computed-origin-method (@@ (guix packages) computed-origin-method)) (define (make-linux-libre-source version upstream-source diff --git a/guix/packages.scm b/guix/packages.scm index ad7937b4fb..8c3a0b0b7b 100644 --- a/guix/packages.scm +++ b/guix/packages.scm @@ -1,6 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021 Ludovic Courtès -;;; Copyright © 2014, 2015, 2017, 2018 Mark H Weaver +;;; Copyright © 2014, 2015, 2017, 2018, 2019 Mark H Weaver ;;; Copyright © 2015 Eric Bavier ;;; Copyright © 2016 Alex Kost ;;; Copyright © 2017, 2019, 2020 Efraim Flashner @@ -344,6 +344,27 @@ name of its URI." ;; git, svn, cvs, etc. reference #f)))) +;; Work around limitations in the 'snippet' mechanism. It is not possible for +;; a 'snippet' to produce a tarball with a different base name than the +;; original downloaded source. Moreover, cherry picking dozens of upsteam +;; patches and applying them suddenly is often impractical; especially when a +;; comprehensive code reformatting is done upstream. Mainly designed for +;; Linux and IceCat packages. +;; XXXX: do not make part of public API (export) such radical capability +;; before a detailed review process. +(define* (computed-origin-method gexp-promise hash-algo hash + #:optional (name "source") + #:key (system (%current-system)) + (guile (default-guile))) + "Return a derivation that executes the G-expression that results +from forcing GEXP-PROMISE." + (mlet %store-monad ((guile (package->derivation guile system))) + (gexp->derivation (or name "computed-origin") + (force gexp-promise) + #:graft? #f ;nothing to graft + #:system system + #:guile-for-build guile))) + (define %supported-systems ;; This is the list of system types that are supported. By default, we -- 2.32.0 From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 11:53:40 2021 Received: (at 50620) by debbugs.gnu.org; 16 Sep 2021 15:53:40 +0000 Received: from localhost ([127.0.0.1]:56285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQthj-0006L3-Jw for submit@debbugs.gnu.org; Thu, 16 Sep 2021 11:53:40 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:56317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQthe-0006Kj-UC for 50620@debbugs.gnu.org; Thu, 16 Sep 2021 11:53:38 -0400 Received: by mail-wm1-f66.google.com with SMTP id 70so2242728wme.5 for <50620@debbugs.gnu.org>; Thu, 16 Sep 2021 08:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=vY1Of2b2Rph2qBPgIbgurnbrBvLf2E/MS4GQOpN37zs=; b=kukFGj4jAkp79g79rOWazimPpVsCfK6N+4BGMfJxmDOCJyynJZPsLkadQYspX8FatR k7ndbmq1u9Sor95gZx3dkP7TEKbWiu1UhxV6y4qj3VjIP2BMw4sANcMeRjq2GqKHyDqH qgIIWsfLtSVgKVkSKpQ5WK9s9b45Dgih1HOLj6hfnWogYEJQq1XDDM61uNeIKYBtRZXw fvtvs58TV1wixQ9zhLm8ctm/4zNvcikc8YW1SSgDXP+IEDFqb6370LDKjm/pX7Nti/Wo yXB6YriPD0VNbJCzqPBjCi7U9HKeqNc6eRB4NG786XzPj6yRIpuHOt80aeYbK3YDGUIi XWsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=vY1Of2b2Rph2qBPgIbgurnbrBvLf2E/MS4GQOpN37zs=; b=Bag4yn0zrMBts7J8DHjEB2Ed03ARFW6rAE1LkE7lVkSN9u9S8E8vyO6WXw6t1Ba+LX 6u/y20RPQ9HhgGbPPrg1W+UBdMgr1RWcYh0mlcYeJGB+ypTp485pERH28AxRxnxYLIGx gGtxQwfxb99AitH+Iq0I8wmGWZ2aLGEL0+bNIpbUK+P/BtiBKG+MwSkdKaV2ffgHa74q ix8nzaMd/kt7gIoUFOFitcrUvpw4fDmq3PhTUGJTk6iSn4qNCCGunXow9EwMIRkAmjyL VLLRzK6DFMqJ2Uq9EVOfqt7wpoP07HFyP5R38Sw7OhBhB++oqweOwGZ47F/1oZZPHU/D 4lkg== X-Gm-Message-State: AOAM5323dGJN4abX8B1Ui77aWmyHWrd6irHYvf848JCOs9hr6m77Bdfc pFiHLKsGPHEJbNyYiVqo47k= X-Google-Smtp-Source: ABdhPJx4NfjDmjiJkXn2QtCqKkgwh89uXOZi+xvYgyn1i2pmwWiaEXhiXqc4u9J+UCZZNi8vyEX1tA== X-Received: by 2002:a05:600c:20c:: with SMTP id 12mr5704328wmi.90.1631807608731; Thu, 16 Sep 2021 08:53:28 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id o17sm3941304wrj.96.2021.09.16.08.53.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 08:53:27 -0700 (PDT) Message-ID: <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun , 50620@debbugs.gnu.org Date: Thu, 16 Sep 2021 17:53:26 +0200 In-Reply-To: <20210916114734.2686426-1-zimon.toutoune@gmail.com> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 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: -1.0 (-) Hi, Am Donnerstag, den 16.09.2021, 13:47 +0200 schrieb zimoun: > The 'computed-origin-method' had been introduced as a workaround > limitations in the 'snippet' mechanism. The procedure is duplicated > which makes hard to automatically detects packages using it. > > * guix/packages.scm (computed-origin-method): Move procedure from... > * gnu/packages/gnuzilla.scm: ...here and... > * gnu/packages/gnuzilla.scm: ...there. > --- > gnu/packages/gnuzilla.scm | 14 ++------------ > gnu/packages/linux.scm | 14 ++------------ > guix/packages.scm | 23 ++++++++++++++++++++++- > 3 files changed, 26 insertions(+), 25 deletions(-) > > diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm > index 431b487fd0..9f6e1f24e1 100644 > --- a/gnu/packages/gnuzilla.scm > +++ b/gnu/packages/gnuzilla.scm > @@ -682,18 +682,8 @@ in C/C++.") > ("1j6l66v1xw27z8w78mpsnmqgv8m277mf4r0hgqcrb4zx7xc2vqyy" > "527e5e090608" "zh-CN") > ("1frwx35klpyz3sdwrkz7945ivb2dwaawhhyfnz4092h9hn7rc4ky" > "6cd366ad2947" "zh-TW"))) > > -(define* (computed-origin-method gexp-promise hash-algo hash > - #:optional (name "source") > - #:key (system (%current-system)) > - (guile (default-guile))) > - "Return a derivation that executes the G-expression that results > -from forcing GEXP-PROMISE." > - (mlet %store-monad ((guile (package->derivation guile system))) > - (gexp->derivation (or name "computed-origin") > - (force gexp-promise) > - #:graft? #f ;nothing to graft > - #:system system > - #:guile-for-build guile))) > +;; XXXX: Workaround 'snippet' limitations. > +(define computed-origin-method (@@ (guix packages) computed-origin- > method)) > > (define %icecat-version "78.14.0-guix0-preview1") > (define %icecat-build-id "20210907000000") ;must be of the form > YYYYMMDDhhmmss > diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm > index 285eb132f4..eb792be9a3 100644 > --- a/gnu/packages/linux.scm > +++ b/gnu/packages/linux.scm > @@ -216,18 +216,8 @@ defconfig. Return the appropriate make target > if applicable, otherwise return > (file-name (string-append "linux-libre-deblob-check-" > version "-" gnu-revision)) > (sha256 deblob-check-hash)))) > > -(define* (computed-origin-method gexp-promise hash-algo hash > - #:optional (name "source") > - #:key (system (%current-system)) > - (guile (default-guile))) > - "Return a derivation that executes the G-expression that results > -from forcing GEXP-PROMISE." > - (mlet %store-monad ((guile (package->derivation guile system))) > - (gexp->derivation (or name "computed-origin") > - (force gexp-promise) > - #:graft? #f ;nothing to graft > - #:system system > - #:guile-for-build guile))) > +;; XXXX: Workaround 'snippet' limitations > +(define computed-origin-method (@@ (guix packages) computed-origin- > method)) > > (define (make-linux-libre-source version > upstream-source > diff --git a/guix/packages.scm b/guix/packages.scm > index ad7937b4fb..8c3a0b0b7b 100644 > --- a/guix/packages.scm > +++ b/guix/packages.scm > @@ -1,6 +1,6 @@ > ;;; GNU Guix --- Functional package management for GNU > ;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, > 2020, 2021 Ludovic Courtès > -;;; Copyright © 2014, 2015, 2017, 2018 Mark H Weaver > > +;;; Copyright © 2014, 2015, 2017, 2018, 2019 Mark H Weaver < > mhw@netris.org> > ;;; Copyright © 2015 Eric Bavier > ;;; Copyright © 2016 Alex Kost > ;;; Copyright © 2017, 2019, 2020 Efraim Flashner < > efraim@flashner.co.il> > @@ -344,6 +344,27 @@ name of its URI." > ;; git, svn, cvs, etc. reference > #f)))) > > +;; Work around limitations in the 'snippet' mechanism. It is not > possible for > +;; a 'snippet' to produce a tarball with a different base name than > the > +;; original downloaded source. Moreover, cherry picking dozens of > upsteam > +;; patches and applying them suddenly is often impractical; > especially when a > +;; comprehensive code reformatting is done upstream. Mainly > designed for > +;; Linux and IceCat packages. > +;; XXXX: do not make part of public API (export) such radical > capability > +;; before a detailed review process. > +(define* (computed-origin-method gexp-promise hash-algo hash > + #:optional (name "source") > + #:key (system (%current-system)) > + (guile (default-guile))) > + "Return a derivation that executes the G-expression that results > +from forcing GEXP-PROMISE." > + (mlet %store-monad ((guile (package->derivation guile system))) > + (gexp->derivation (or name "computed-origin") > + (force gexp-promise) > + #:graft? #f ;nothing to graft > + #:system system > + #:guile-for-build guile))) > + > > (define %supported-systems > ;; This is the list of system types that are supported. By > default, we I think that rather than putting this into (guix packages) itself, we might want to put it into its own file like (guix computed-origins) and choose a method name that is actually a verb, similar to git-fetch or svn-fetch. Perhaps simply call it compute-origin? If done this way, there'd be the benefit that modules with packages using this thing would have to explicitly request the presence of the symbol through their use-modules clauses. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 19:40:15 2021 Received: (at 50620) by debbugs.gnu.org; 16 Sep 2021 23:40:15 +0000 Received: from localhost ([127.0.0.1]:57868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR0zG-0004ck-R9 for submit@debbugs.gnu.org; Thu, 16 Sep 2021 19:40:15 -0400 Received: from world.peace.net ([64.112.178.59]:59558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR0zF-0004cT-Fh for 50620@debbugs.gnu.org; Thu, 16 Sep 2021 19:40:13 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mR0z8-0007jB-TD; Thu, 16 Sep 2021 19:40:06 -0400 From: Mark H Weaver To: Liliana Marie Prikler Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. In-Reply-To: <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> References: <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <20210916114734.2686426-1-zimon.toutoune@gmail.com> Date: Thu, 16 Sep 2021 19:38:22 -0400 Message-ID: <87v930ay5y.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 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: -1.0 (-) Hi Liliana, Liliana Marie Prikler wrote: > I think that rather than putting this into (guix packages) itself, we > might want to put it into its own file like (guix computed-origins) and > choose a method name that is actually a verb, similar to git-fetch or > svn-fetch. Perhaps simply call it compute-origin? These suggestions sound fine to me, although I don't have a strong opinion either way. I'm happy to leave these details to others to decide. > If done this way, there'd be the benefit that modules with packages > using this thing would have to explicitly request the presence of the > symbol through their use-modules clauses. Actually, for better or worse, Guile's '@@' form does not require the named module to be imported using 'use-modules', so I don't think this benefit strictly exists as stated above. However, I agree that it's good practice to list all imported modules in the '#:use-module' clauses at the top of the file wherever possible [*], and that there may be some benefit in declaring the use of 'computed-origins' at the top of each file. Thanks, Mark [*] It's not always possible in the presence of cyclic module dependencies. -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about . From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 17 04:41:23 2021 Received: (at 50620) by debbugs.gnu.org; 17 Sep 2021 08:41:23 +0000 Received: from localhost ([127.0.0.1]:58455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR9Qx-0002GI-Ff for submit@debbugs.gnu.org; Fri, 17 Sep 2021 04:41:23 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]:44977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR9Qs-0002Fx-3G for 50620@debbugs.gnu.org; Fri, 17 Sep 2021 04:41:22 -0400 Received: by mail-qk1-f175.google.com with SMTP id c10so15118553qko.11 for <50620@debbugs.gnu.org>; Fri, 17 Sep 2021 01:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3/IKjJ8ZTRdBg3zthUy35V8SYvOIJhiExKuYnmw30i0=; b=AQOf0M+Lhqd5z4Fx9B2tHmOyRIEbKjSTAaHvvqGOkT5YgZTZRY1CFnzmNOT7OJYz+Y fdffioyBTqM+HnbM884ExkHD74vmKudsRbTlDmqDFatYNE0oPuJM6IARKzmrYDAyxWqv JWbzxGibzQufIxLW+BOSBt3gqBdKKeaj+XMRGiRiIyIX0QC5IY41OZu8uaFsQQHZ3AkA qeZdZpeFyJ+hS6x/fHvOGqJEVpYMoLpVhn2C+rBn6SrIAkuWAoP+cxCQNmAyIpbUE10s Bq16Lr0bzjKhwXGplOS9jTegN+K5xU4Ujfa3jKJ9451iEkmg+abEqtSRGuLuGjX779r5 EoOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3/IKjJ8ZTRdBg3zthUy35V8SYvOIJhiExKuYnmw30i0=; b=5Vbgn5JXsjKl/kn/o//Ua1aj95NjClf/yj/ypeVJrWOyD/7+BZ6ZNj8pZb2ebxYW+J 4weGQfLJFpiIhreqeGWe6N771AsIekiah3dcJpzPJl8E0uT6vlM+iG5JDvUvHU+h0hLe Z4gfUc0NIP/RhEd4OyGlsqzEKxXhIOb9guG/T0krkSB3CR2REUUsD5VPQmYa2UGvP6h9 ZfNQhZQyoEwqpurLfffMf2Ii0LghZiMH25o/WEe7kGxUC730dYpnNb754NkfH2aBnMRI en444x1c2GmEziMs7JMHCvMA9DHKUQw5dVbXp/DFlG2rkKHZikZufhCSk8qM2plyqp7U WcuQ== X-Gm-Message-State: AOAM530TeNGPYT32Lz1cbPbc41Bj//Yop5bXBdOKbdfN5U8DRSVkhqMY axMhMw2t0Y351m+w8ncVExLvBEUgWevu0EWJUtc= X-Google-Smtp-Source: ABdhPJzRpxDrhfl2poy15o6KBUgDOCuJ98zUZHB+HnqVcPgeR9nXZUTL39XZb8lGjp9AhmPk5tbSxuFFS1c6Fy86zkQ= X-Received: by 2002:a37:a3cd:: with SMTP id m196mr9341312qke.253.1631868072343; Fri, 17 Sep 2021 01:41:12 -0700 (PDT) MIME-Version: 1.0 References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> In-Reply-To: <87v930ay5y.fsf@netris.org> From: zimoun Date: Fri, 17 Sep 2021 10:41:01 +0200 Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. To: Mark H Weaver Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Liliana Marie Prikler , 50620@debbugs.gnu.org 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: -1.0 (-) Hi Liliana and Mark, Thanks for the comments. On Fri, 17 Sept 2021 at 01:40, Mark H Weaver wrote: > Liliana Marie Prikler wrote: > > I think that rather than putting this into (guix packages) itself, we > > might want to put it into its own file like (guix computed-origins) and > > choose a method name that is actually a verb, similar to git-fetch or > > svn-fetch. Perhaps simply call it compute-origin? > > These suggestions sound fine to me, although I don't have a strong > opinion either way. I'm happy to leave these details to others to > decide. I do not have a strong opinion either. If no one comes with a better name, I will pick the suggested one. :-) There are only two hard things in Computer Science: cache invalidation and naming things. -- Internet > > If done this way, there'd be the benefit that modules with packages > > using this thing would have to explicitly request the presence of the > > symbol through their use-modules clauses. > > Actually, for better or worse, Guile's '@@' form does not require the > named module to be imported using 'use-modules', so I don't think this > benefit strictly exists as stated above. However, I agree that it's > good practice to list all imported modules in the '#:use-module' clauses > at the top of the file wherever possible [*], and that there may be some > benefit in declaring the use of 'computed-origins' at the top of each > file. I am not deeply familiar with Guile module. I chose to put this in (guix packages) instead of its own module because the module would contain only one function and nothing exported. The aim for now, as discussed, is to not make this 'method' part of the public API. Then if the function is not exported by the module, the '#:use-module' does not have an effect, right? In this case, does it make sense to put this in its own module? Initially, I put the '@@' right after the '#:use-module's but then I changed my mind; I do not remember why. Anyway, yeah it is better at the top. Cheers, simon From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 28 05:38:48 2021 Received: (at 50620) by debbugs.gnu.org; 28 Sep 2021 09:38:48 +0000 Received: from localhost ([127.0.0.1]:43876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mV9ZY-0007Bd-2R for submit@debbugs.gnu.org; Tue, 28 Sep 2021 05:38:48 -0400 Received: from world.peace.net ([64.112.178.59]:49886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mV9ZW-0007BO-A0 for 50620@debbugs.gnu.org; Tue, 28 Sep 2021 05:38:46 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mV9Z5-0000rW-Ib; Tue, 28 Sep 2021 05:38:19 -0400 From: Mark H Weaver To: zimoun Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> Date: Tue, 28 Sep 2021 05:36:48 -0400 Message-ID: <87pmstghx0.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Liliana Marie Prikler , 50620@debbugs.gnu.org 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: -1.0 (-) Hi Simon, zimoun writes: > On Fri, 17 Sept 2021 at 01:40, Mark H Weaver wrote: >> Liliana Marie Prikler wrote: [...] >> > If done this way, there'd be the benefit that modules with packages >> > using this thing would have to explicitly request the presence of the >> > symbol through their use-modules clauses. >> >> Actually, for better or worse, Guile's '@@' form does not require the >> named module to be imported using 'use-modules', so I don't think this >> benefit strictly exists as stated above. However, I agree that it's >> good practice to list all imported modules in the '#:use-module' clauses >> at the top of the file wherever possible [*], and that there may be some >> benefit in declaring the use of 'computed-origins' at the top of each >> file. > > I am not deeply familiar with Guile module. > > I chose to put this in (guix packages) instead of its own module > because the module would contain only one function and nothing > exported. The aim for now, as discussed, is to not make this 'method' > part of the public API. > > Then if the function is not exported by the module, the '#:use-module' > does not have an effect, right? It's true that it would have no effect on the set of available bindings, and that's an excellent point. Perhaps Liliana could clarify what she had in mind, or better yet, propose a patch. Please don't let me be a blocker on this thread. I contributed a few thoughts, but I don't have time right now to shepherd this issue, sorry. Regards, Mark -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about . From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 28 12:02:04 2021 Received: (at 50620) by debbugs.gnu.org; 28 Sep 2021 16:02:04 +0000 Received: from localhost ([127.0.0.1]:46760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVFYS-0004we-7y for submit@debbugs.gnu.org; Tue, 28 Sep 2021 12:02:04 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:36440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVFYM-0004w6-L0 for 50620@debbugs.gnu.org; Tue, 28 Sep 2021 12:02:02 -0400 Received: by mail-wr1-f66.google.com with SMTP id g16so58936326wrb.3 for <50620@debbugs.gnu.org>; Tue, 28 Sep 2021 09:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version; bh=IxM5UgeJGpQnUDmMsd6rP22VIUDbJ4knH5+UMAdA/p0=; b=IWmAS3pHGBqBpelbw14TFVilnAl/IhZp0YtYzTFApzg90U+vYtlSd9wBufKTfFDdDu knjxq6O4A2ruNHFPe6UriQSeENwT+JIlYu07Aoo2F4TaYv9qBYcctO2eJB94IJb8XFGM glpckUsf+fd++y/ZNnDLF+VER7nmMZ91LINkEtX5TKUc24KajE5dPHmnnSUb/yERe5kj 7GXZ6I4VGAwcPiCKreieisa2rjlg9kM8wMJUSINgqMRtQ9Xkqpsi96G+t1zsB9/8NgZI r44kqtYOUxQySDJEDIa0mTF6LnCYErk9OgKhZsuXOXRwizSmZ3WhWrCB9TQQWmjOxPIe BdFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version; bh=IxM5UgeJGpQnUDmMsd6rP22VIUDbJ4knH5+UMAdA/p0=; b=NuX1b9OF1PUWrOfeDUZSn1iTaZ5YghbAb9l53sw1wSyu1DX3swtGnwiMosO6J79mhy Wy88XDf0Vc1yimahu7uxj4jmd8hcI0o+LbPYsj6AfYvbrewtUZqLNSLMpIIQwVl0T2zZ CXVpsDLQadgR96xWSVFTxPOnQcL1Opw+KGZXVWrcw6YNPFhKjUzyk0ljkHdFXHI1vDQC EYR1vi5owpVECjiVTbQWog1Zv79CTniVQ1Uk+3BEvJY42bTBvRWnZNqUjSTXCY4jd72u C4d4LBjDyC2wfxTeVUH5jamGJl6w20tS2wfs1sj+mNdY7VO0L3wdB3IzqcICW350W+3h NTIw== X-Gm-Message-State: AOAM5317GxkF/0f/D66TJAW5cBxaXQvDijd9kHMdguoZfGIn7nDqYx3l cbee1ZiYMmUodANIUYriw7I= X-Google-Smtp-Source: ABdhPJzSFDhvGUrTiIHCrfn5E9XFc4k2ksFLOyZ5s76NgnLYOHgjYecj0riOPd64AX3NlYsiVwn8Kg== X-Received: by 2002:a5d:4608:: with SMTP id t8mr1056448wrq.136.1632844912795; Tue, 28 Sep 2021 09:01:52 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id e21sm3130424wme.42.2021.09.28.09.01.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 09:01:52 -0700 (PDT) Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: Mark H Weaver , zimoun Date: Tue, 28 Sep 2021 18:01:51 +0200 In-Reply-To: <87pmstghx0.fsf@netris.org> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> Content-Type: multipart/mixed; boundary="=-qrcXMPYMoD8D+wjRq+BR" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 50620@debbugs.gnu.org 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: -1.0 (-) --=-qrcXMPYMoD8D+wjRq+BR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi everyone, Am Dienstag, den 28.09.2021, 05:36 -0400 schrieb Mark H Weaver: > Hi Simon, > > zimoun writes: > > On Fri, 17 Sept 2021 at 01:40, Mark H Weaver > > wrote: > > > Liliana Marie Prikler wrote: > [...] > > > > If done this way, there'd be the benefit that modules with > > > > packages > > > > using this thing would have to explicitly request the presence > > > > of the > > > > symbol through their use-modules clauses. > > > > > > Actually, for better or worse, Guile's '@@' form does not require > > > the named module to be imported using 'use-modules', so I don't > > > think this benefit strictly exists as stated above. However, I > > > agree that it's good practice to list all imported modules in > > > the '#:use-module' clauses at the top of the file wherever > > > possible [*], and that there may be somebenefit in declaring the > > > use of 'computed-origins' at the top of each file. > > > > I am not deeply familiar with Guile module. > > > > I chose to put this in (guix packages) instead of its own module > > because the module would contain only one function and nothing > > exported. The aim for now, as discussed, is to not make this > > 'method' part of the public API. If so, one could argue that (gnu packages) is a better location to hide it, but my main issue is that we still need to hide it! This will cause other channels to refer to it using @@ or roll their own implementations. > > Then if the function is not exported by the module, the '#:use- > > module' does not have an effect, right? > > It's true that it would have no effect on the set of available > bindings, and that's an excellent point. Perhaps Liliana could > clarify what she had in mind, or better yet, propose a patch. I would argue that something like computed-origin-method *does* deserve to be an exported binding, but ought not to be grouped together into (guix packages). The latter only provides record types, not methods (which are typically implemented elsewhere), and I'd like to keep it that way. I've attached a patch to illustrate my point, but please don't apply it as is. I have not put in the necessary git blame research to find out who would need to be copyrighted here. Regards, Liliana --=-qrcXMPYMoD8D+wjRq+BR Content-Disposition: attachment; filename="0001-guix-Add-computed-origins.patch" Content-Type: text/x-patch; name="0001-guix-Add-computed-origins.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSBlYTEzOGZkYjE0NTIyNGEwNGEyYmFkMjdlMjE0ZGY3ZTI4M2NjZWU3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBMaWxpYW5hIE1hcmllIFByaWtsZXIgPGxpbGlhbmEucHJpa2xl ckBnbWFpbC5jb20+CkRhdGU6IFR1ZSwgMjggU2VwIDIwMjEgMTc6NTQ6MjMgKzAyMDAKU3ViamVj dDogW1BBVENIXSBndWl4OiBBZGQgY29tcHV0ZWQtb3JpZ2lucy4KTUlNRS1WZXJzaW9uOiAxLjAK Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQtVHJhbnNmZXIt RW5jb2Rpbmc6IDhiaXQKClRoaXMgYWRkcyB0aGUg4oCYY29tcHV0ZWQtb3JpZ2luLW1ldGhvZOKA mSB1c2VkIGJ5IGxpbnV4LWxpYnJlIG9yIGljZWNhdCB1bmRlcgp0aGUgbmV3IG5hbWUg4oCYY29t cHV0ZS1vcmlnaW7igJkgYXMgcHVibGljIEd1aXggQVBJLgoKKiBndWl4L2NvbXB1dGVkLW9yaWdp bnM6IE5ldyBmaWxlLgotLS0KIE1ha2VmaWxlLmFtICAgICAgICAgICAgICAgfCAgMSArCiBndWl4 L2NvbXB1dGVkLW9yaWdpbnMuc2NtIHwgMzcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKwogMiBmaWxlcyBjaGFuZ2VkLCAzOCBpbnNlcnRpb25zKCspCiBjcmVhdGUgbW9kZSAx MDA2NDQgZ3VpeC9jb21wdXRlZC1vcmlnaW5zLnNjbQoKZGlmZiAtLWdpdCBhL01ha2VmaWxlLmFt IGIvTWFrZWZpbGUuYW0KaW5kZXggYjY2Nzg5ZmEwYi4uZThmMGM2M2UyYiAxMDA2NDQKLS0tIGEv TWFrZWZpbGUuYW0KKysrIGIvTWFrZWZpbGUuYW0KQEAgLTk4LDYgKzk4LDcgQEAgTU9EVUxFUyA9 CQkJCQlcCiAgIGd1aXgvYnpyLWRvd25sb2FkLnNjbSAgICAgICAgICAgIAkJXAogICBndWl4L2dp dC1kb3dubG9hZC5zY20JCQkJXAogICBndWl4L2hnLWRvd25sb2FkLnNjbQkJCQlcCisgIGd1aXgv Y29tcHV0ZWQtb3JpZ2lucy5zY20JCQkJXAogICBndWl4L3N3aC5zY20JCQkJCVwKICAgZ3VpeC9t b25hZHMuc2NtCQkJCVwKICAgZ3VpeC9tb25hZC1yZXBsLnNjbQkJCQlcCmRpZmYgLS1naXQgYS9n dWl4L2NvbXB1dGVkLW9yaWdpbnMuc2NtIGIvZ3VpeC9jb21wdXRlZC1vcmlnaW5zLnNjbQpuZXcg ZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwLi5mN2M4M2RmMGJmCi0tLSAvZGV2L251 bGwKKysrIGIvZ3VpeC9jb21wdXRlZC1vcmlnaW5zLnNjbQpAQCAtMCwwICsxLDM3IEBACis7Ozsg R05VIEd1aXggLS0tIEZ1bmN0aW9uYWwgcGFja2FnZSBtYW5hZ2VtZW50IGZvciBHTlUKKzs7OyBD b3B5cmlnaHQgwqkgMTMxMiBNYXggTcO8bGxlciA8bWF4QG3DvGxsZXIuZ21iaD4KKzs7OworOzs7 IFRoaXMgZmlsZSBpcyBwYXJ0IG9mIEdOVSBHdWl4LgorOzs7Cis7OzsgR05VIEd1aXggaXMgZnJl ZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAorOzs7 IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVi bGlzaGVkIGJ5Cis7OzsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNp b24gMyBvZiB0aGUgTGljZW5zZSwgb3IgKGF0Cis7OzsgeW91ciBvcHRpb24pIGFueSBsYXRlciB2 ZXJzaW9uLgorOzs7Cis7OzsgR05VIEd1aXggaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh dCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0Cis7OzsgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhv dXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorOzs7IE1FUkNIQU5UQUJJTElUWSBvciBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKzs7OyBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorOzs7Cis7OzsgWW91IHNob3VsZCBo YXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKzs7 OyBhbG9uZyB3aXRoIEdOVSBHdWl4LiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9s aWNlbnNlcy8+LgorCisoZGVmaW5lLW1vZHVsZSAoZ3VpeCBjb21wdXRlZC1vcmlnaW5zKQorICAj OnVzZS1tb2R1bGUgKGd1aXggbW9uYWRzKQorICAjOnVzZS1tb2R1bGUgKGd1aXggc3RvcmUpCisg ICM6dXNlLW1vZHVsZSAoZ3VpeCBwYWNrYWdlcykKKyAgIzp1c2UtbW9kdWxlIChndWl4IGdleHAp CisgICM6ZXhwb3J0IChjb21wdXRlLW9yaWdpbikpCisKKyhkZWZpbmUqIChjb21wdXRlLW9yaWdp biBnZXhwLXByb21pc2UgaGFzaC1hbGdvIGhhc2gKKyAgICAgICAgICAgICAgICAgICAgICAgICAj Om9wdGlvbmFsIChuYW1lICJzb3VyY2UiKQorICAgICAgICAgICAgICAgICAgICAgICAgICM6a2V5 IChzeXN0ZW0gKCVjdXJyZW50LXN5c3RlbSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgKGd1 aWxlIChkZWZhdWx0LWd1aWxlKSkpCisgICJSZXR1cm4gYSBkZXJpdmF0aW9uIHRoYXQgZXhlY3V0 ZXMgdGhlIEctZXhwcmVzc2lvbiB0aGF0IHJlc3VsdHMKK2Zyb20gZm9yY2luZyBHRVhQLVBST01J U0UuIgorICAobWxldCAlc3RvcmUtbW9uYWQgKChndWlsZSAocGFja2FnZS0+ZGVyaXZhdGlvbiBn dWlsZSBzeXN0ZW0pKSkKKyAgICAoZ2V4cC0+ZGVyaXZhdGlvbiAob3IgbmFtZSAiY29tcHV0ZWQt b3JpZ2luIikKKyAgICAgICAgICAgICAgICAgICAgICAoZm9yY2UgZ2V4cC1wcm9taXNlKQorICAg ICAgICAgICAgICAgICAgICAgICM6Z3JhZnQ/ICNmICAgICAgIDtub3RoaW5nIHRvIGdyYWZ0Cisg ICAgICAgICAgICAgICAgICAgICAgIzpzeXN0ZW0gc3lzdGVtCisgICAgICAgICAgICAgICAgICAg ICAgIzpndWlsZS1mb3ItYnVpbGQgZ3VpbGUpKSkKLS0gCjIuMzMuMAoK --=-qrcXMPYMoD8D+wjRq+BR-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 28 12:38:04 2021 Received: (at 50620) by debbugs.gnu.org; 28 Sep 2021 16:38:04 +0000 Received: from localhost ([127.0.0.1]:46820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVG7I-0005wR-BF for submit@debbugs.gnu.org; Tue, 28 Sep 2021 12:38:04 -0400 Received: from mail-qv1-f42.google.com ([209.85.219.42]:33508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVG7G-0005vr-Bn for 50620@debbugs.gnu.org; Tue, 28 Sep 2021 12:38:02 -0400 Received: by mail-qv1-f42.google.com with SMTP id a9so13862795qvf.0 for <50620@debbugs.gnu.org>; Tue, 28 Sep 2021 09:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dJzAII08l/uq4zsLNkmscjS2jHukip1wj93M17g+oBU=; b=UjLrxLr9mxjPdKBtlWtKK76eO+aUkiacvB8IN+k7dply0zBCgXm9blTVoPWprqHz0D U1zUe6gnUTFR8kWHSDSo92jdPMl/Rl1mCI84r0NkSXKrbbi6uL6koEiuWn2+F9UFIMK8 9JLIs3FuzwZywyDmvqTFefjRbstsulWBG2XGLiqsDutHPg869SeU+zPcL9Mdq6wJ3Nl5 PEMEQXMeF9zEVF+V5A51guQxUtZp0LQZnTF0+1TJoEEXpEPswWfxRaBsKRchTep79TL6 65+cQvp1Ayq8DWm4yCJ1L+dNDnP0tzGZcnKjp1D+xqQQ820aCsjujMrze2m9DSuEqXsc fZ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dJzAII08l/uq4zsLNkmscjS2jHukip1wj93M17g+oBU=; b=J6nyATPtu8kuKx5Ri9+34L3DeemXtIV9BXnpbVm0KikDVcIBJHBhxgeB7gX14UuQn7 1a/Grg7bYAnuvq2Cp6GX/Qf2/aYyJ0J++RzeMMF/JnRsCxb92GirIYI426q1VFMRWIz6 h4ehbi6xDZ/5LOmfLbqgxAyk6v4j2SMgThULU3XVAtSagdTz7xcM3VqcWAbnnBhl4Vw8 rQgJa+PZ6pDTW9UQ4zJSj9Negd7gFiBLhnZdtAfCPgPf8OauUwVTzzkwXgx5j/poxIEe Am8kitfIoTGFOYQ9rFqU5XpeMTuDkCCeeyXlQBNG/v/FkvJAWvpRT7WchAWg+IL1BjIT nFNg== X-Gm-Message-State: AOAM531weGMYpbEDSvM0efriYo49lkHlCDtRR5EISFop84X6MmDReBl2 of5IKkL6M/+GPiLJSePjqMN/fKe9gPF/WSliHDoP47EGnIM= X-Google-Smtp-Source: ABdhPJww3RLaCCrHLIxqUZZpvJCTmhldLs0XBQaWR/Q2vC0z3/9hiis10cmZtvO2ZaNwRZWWK//cIzJ8UYdAibIxhEc= X-Received: by 2002:a05:6214:2e7:: with SMTP id h7mr6408377qvu.39.1632847076817; Tue, 28 Sep 2021 09:37:56 -0700 (PDT) MIME-Version: 1.0 References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> In-Reply-To: From: zimoun Date: Tue, 28 Sep 2021 18:37:45 +0200 Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. To: Liliana Marie Prikler Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, On Tue, 28 Sept 2021 at 18:01, Liliana Marie Prikler wrote: > > zimoun writes: > > > I chose to put this in (guix packages) instead of its own module > > > because the module would contain only one function and nothing > > > exported. The aim for now, as discussed, is to not make this > > > 'method' part of the public API. > If so, one could argue that (gnu packages) is a better location to hide Ok. I do not find it better than (guix packages) where 'origin' is defined but anyway. I will send a v2 considering this and the rename you proposed. > it, but my main issue is that we still need to hide it! This will > cause other channels to refer to it using @@ or roll their own > implementations. This patch is not about discussing if this method should be public or not. It is private. Please discuss that elsewhere. Mark commented in [0]: --8<---------------cut here---------------start------------->8--- The reason 'computed-origin-method' is not exported is because it never went through the review process that such a radical new capability in Guix should go through before becoming part of it's public API. --8<---------------cut here---------------end--------------->8--- and this patch is about improving the situation (by removing the code duplication). That's all. The aim of this improvement is related to saving these IceCat and Linux Libre packages by Software Heritage [1]. 0: 1: > I've attached a patch to illustrate my point, but please don't apply it > as is. I have not put in the necessary git blame research to find out > who would need to be copyrighted here. As I said, the point of my patch is not to discuss if this 'compute-origin' should be part or not to the public API. It is simply a cleanup to ease the patch#50515 [1]. Therefore, I do not see what is the point to create its own module. All the best, simon From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 28 13:24:49 2021 Received: (at 50620) by debbugs.gnu.org; 28 Sep 2021 17:24:49 +0000 Received: from localhost ([127.0.0.1]:46897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVGqX-0000to-BD for submit@debbugs.gnu.org; Tue, 28 Sep 2021 13:24:49 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:33331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVGqG-0000tJ-4W for 50620@debbugs.gnu.org; Tue, 28 Sep 2021 13:24:48 -0400 Received: by mail-wr1-f68.google.com with SMTP id t18so59396585wrb.0 for <50620@debbugs.gnu.org>; Tue, 28 Sep 2021 10:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=EDxsHEkx+GqjQsz0OfVCyb49nKdEAykkCk6RzT1yE8E=; b=K0vs7E6GcKktJvdy8YRDVHT9wVIrvzAF816Rl2wH8IXxVixkNRTALxUvvCT7jjbiZ1 3eKC8JesMBVr0ACjvCde6aEU52oChqWyxiFu1Tp1oFf88elbZiqjRtmKkeqqYFnhXsPK AgzfsafgN4SyEksLcrXLPuATPiM0vpUZKzJpEEi9Xr+DVDSufdPWnByrbwJGMA26LpeZ i3E+Fp7gbP9oV0NxR6sjgbuvhuhmow4779+QYvbx9FTBapLiMWerRGNFjcFtVMWFQqJ8 Tnl/8ybykREMs5Wx+CEVBUN8kRUa+B2pt6XG1GQCgb+o3QipOOLI9Sf230L6ZUY1HwSa eUtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=EDxsHEkx+GqjQsz0OfVCyb49nKdEAykkCk6RzT1yE8E=; b=SdmzIHdfecvvjjvi+yaLifAO4EHinl3d+F7EPRGLIYckFVlzGMg5aEVGKaiccbV9nt NjTQccfQTftiCG9xIIY4r6sBcKpt7PC8d8sqoGEdYigPh8iAlFm+eqkvlfMOMIX2i4T9 fLQxE1jBchDd6xWBjtuUHA9RyMAZY25vbYFcWkniLaFS+xXEDF/qhgHOwt/d8iiq4tCv AMQXc7AszfuLtXBd6FOGBWIG2F5mSO1ASBdurXA16aBUzcgNWU+OeZs4u6o/NTo8lZa9 zGEDuzIB0w2Z6f/tmnxGMM/jbm40NL6Ssqq07rFZA7D6LHtlAojR09gh75+qojWfzccd gspw== X-Gm-Message-State: AOAM532uYfAo8ielQZhagfQlazqgFcG+XdWhr71MJUyw8WoNEaEhnO/p NJEQ+HwkzLzm3CK9z8n8hJw= X-Google-Smtp-Source: ABdhPJw4ndjhATBwy7RQihOwxv373GsjDRb/hjfMPVnaAYAVRwQA5a31NcYAmLolDL1eW9C+umacTQ== X-Received: by 2002:adf:ea45:: with SMTP id j5mr1498214wrn.291.1632849865321; Tue, 28 Sep 2021 10:24:25 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id t126sm3266346wma.4.2021.09.28.10.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 10:24:24 -0700 (PDT) Message-ID: <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun Date: Tue, 28 Sep 2021 19:24:23 +0200 In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, Am Dienstag, den 28.09.2021, 18:37 +0200 schrieb zimoun: > Hi, > > On Tue, 28 Sept 2021 at 18:01, Liliana Marie Prikler > wrote: > > > zimoun writes: > > > > I chose to put this in (guix packages) instead of its own > > > > module > > > > because the module would contain only one function and nothing > > > > exported. The aim for now, as discussed, is to not make this > > > > 'method' part of the public API. > > If so, one could argue that (gnu packages) is a better location to > > hide > > Ok. I do not find it better than (guix packages) where 'origin' is > defined but anyway. > I will send a v2 considering this and the rename you proposed. By that logic all of (guix git-download), (guix svn-download), etc. could be inlined there as well. Obviously that's a bad idea, but *why* is it a bad idea? I'd argue it's because we have a clear separation of the record descriptor for an origin and the ways it can be computed (the former in (guix packages), the latter elsewhere) and that it's good to keep those concerns separate. I also personally find the name "computed-origin" to be somewhat weird naming choice. I could just as well write the entire source code for some given package in the snippet part of an origin, perhaps applying some weird tricks in the category of Kolmogorov code golf – would that origin not be computed? > > it, but my main issue is that we still need to hide it! This will > > cause other channels to refer to it using @@ or roll their own > > implementations. > > This patch is not about discussing if this method should be public or > not. It is private. Please discuss that elsewhere. > > Mark commented in [0]: > > --8<---------------cut here---------------start------------->8--- > The reason 'computed-origin-method' is not exported is because it > never went through the review process that such a radical new > capability in Guix should go through before becoming part of it's > public API. > --8<---------------cut here---------------end--------------->8--- > > and this patch is about improving the situation (by removing the code > duplication). That's all. The aim of this improvement is related to > saving these IceCat and Linux Libre packages by Software Heritage > [1]. I don't think delaying this review is a good idea, though. When you're removing code duplication, you ought to do it in a way that all duplicated code can indeed be removed, at least in my opinion. As-is this patch just invites practises otherwise discouraged by Guix. Cheers From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 04:32:43 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 08:32:44 +0000 Received: from localhost ([127.0.0.1]:47716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVV19-0002bl-FO for submit@debbugs.gnu.org; Wed, 29 Sep 2021 04:32:43 -0400 Received: from mail-qk1-f182.google.com ([209.85.222.182]:39541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVV15-0002bT-MX for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 04:32:41 -0400 Received: by mail-qk1-f182.google.com with SMTP id f130so1545658qke.6 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 01:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oROIWW20I27N1+hEPZqehSNrLmUZ05mPcIL1m5nFSdI=; b=ksAM6DUhfQ1bw+G38kK/xX3xQmb6m0WSpbpJD+Q0EDVMhD9JV/tFvOMdTGP+of8+W5 835NVg1FLAs93wizisPr+c1yNY4U4LhDWV56scSIRmWeKlnt34BMqcXbtuCITiyGanoI hluaja+TsEqkd8mWoiduQDeN4yqM1CQzx+L+00Cvvo3i4maJiUko6SGAKaNeYw2zVmEy /ok+2Es/E9hEzKABI4xDoNjpR/312wNsfOFjFNTc6oeJCV6efrU1tg09NzQyEPdPn0iU FPU27lhAlVhFxAkTcj498LGQSJg4Dlq7xOgcCpS9MnzKKk01cMO5pjNzpch2Z/77GR0q dlsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oROIWW20I27N1+hEPZqehSNrLmUZ05mPcIL1m5nFSdI=; b=YrgBiIqGc+q88o7RRBJlsRWSeRnq2o8s7EaN8mqo1yd+XCNbQO2FO3OclO7OU0dS49 ZVP4Uy3//FdmtgdCajWoeDizmKsI+LMau8JLVQbZmsPGHTBP2ZUKqeKgLnjdYKdXYfWH i050cGmDWSFsVSWwXyVWGf1ezAqM4pN+u7wrfTZoLS1TnorZs6i44tLNfRaiTWo9RjzI 2TNosUrDiwIOuT0GlAVvMJ7EzeArLIy7aYUeI4IlJbWdikImtG1jHrckADDq6mlhoVAK sJcC4Zv47gb5x5khHJtRlc3c1RgDlOueqA8wrxr9dQ1j4Yh0kbMgJbZOgLOLyz1cwUU3 zMvQ== X-Gm-Message-State: AOAM533zsAsJDS3EcORKb8Ghn5M7NtkVH6zRNO87duvw/ggGDiKNmqWF HsWiCeYH/Idzowe5bEu8/asqPJXRqQwcVltd5Ms= X-Google-Smtp-Source: ABdhPJy98comwy6HXKaqXnSUS/q8d1Sx2J0HpCSGE/NgBpOUo8Zi4VMX50SVgDh8FjDdgZDLN0NFzHIlUTuYeZgiqck= X-Received: by 2002:a37:2d04:: with SMTP id t4mr3880795qkh.463.1632904353993; Wed, 29 Sep 2021 01:32:33 -0700 (PDT) MIME-Version: 1.0 References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> In-Reply-To: <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> From: zimoun Date: Wed, 29 Sep 2021 10:32:22 +0200 Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. To: Liliana Marie Prikler Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, On Tue, 28 Sept 2021 at 19:24, Liliana Marie Prikler wrote: > > Ok. I do not find it better than (guix packages) where 'origin' is > > defined but anyway. > > I will send a v2 considering this and the rename you proposed. > > By that logic all of (guix git-download), (guix svn-download), etc. > could be inlined there as well. Obviously that's a bad idea, but *why* > is it a bad idea? I'd argue it's because we have a clear separation of > the record descriptor for an origin and the ways it can be computed > (the former in (guix packages), the latter elsewhere) and that it's > good to keep those concerns separate. > > I also personally find the name "computed-origin" to be somewhat weird > naming choice. I could just as well write the entire source code for > some given package in the snippet part of an origin, perhaps applying > some weird tricks in the category of Kolmogorov code golf =E2=80=93 would= that > origin not be computed? Are we bikeshedding here? ;-) Again, the aim of this patch it not to fix the 'computed-origin-method'. The aim of this patch is to improve the readibility of the patch#50515 [1] which allows linux-libre and icecat to be ingested by SWH from 'guix.gnu.org/sources.json'. Maybe there is an original issue with 'computed-origin-method', as Mark explained [0]. But that's another story than the SWH and sources.json one! --8<---------------cut here---------------start------------->8--- At the time that I added 'computed-origin-method', I was under time pressure to push security updates for IceCat, and my previous method of cherry picking dozens of upsteam patches and applying them to the most recent IceCat release suddenly became impractical due to comprehensive code reformatting done upstream. I've always viewed 'computed-origin-method' as a temporary hack to work around limitations in the 'snippet' mechanism. Most importantly, last I checked, it was not possible for a 'snippet' to produce a tarball with a different base name than the original downloaded source. I consider it a *requirement* for the 'icecat' source tarball and it's unpacked directory to be named "icecat-=E2=80=A6" and not "firefox-=E2=80=A6", and s= imilarly for'linux-libre'. --8<---------------cut here---------------end--------------->8--- 0: 1: > > > it, but my main issue is that we still need to hide it! This will > > > cause other channels to refer to it using @@ or roll their own > > > implementations. > > > > This patch is not about discussing if this method should be public or > > not. It is private. Please discuss that elsewhere. > > > > Mark commented in [0]: > > > > --8<---------------cut here---------------start------------->8--- > > The reason 'computed-origin-method' is not exported is because it > > never went through the review process that such a radical new > > capability in Guix should go through before becoming part of it's > > public API. > > --8<---------------cut here---------------end--------------->8--- > > > > and this patch is about improving the situation (by removing the code > > duplication). That's all. The aim of this improvement is related to > > saving these IceCat and Linux Libre packages by Software Heritage > > [1]. > > I don't think delaying this review is a good idea, though. When you're > removing code duplication, you ought to do it in a way that all > duplicated code can indeed be removed, at least in my opinion. As-is > this patch just invites practises otherwise discouraged by Guix. If you go this road, please push patch#50515 [1] as-is. It perfectly works and fixes the issue with 'guix.gnu.org/sources.json' and SWH. This current patch#50620 is a way to improve the readibility of patch#50515 but then reading all this discussion I miss why patch#50620 is thus a blocker for patch#50515. Because I feel we are entering into the famous "Bigger problem" from xkcd. ;-) Patch#50515 is the first part of a concrete answer to and . It is discussed to use SWH for such situations but today our linux-libre is not ingested by SWH. Therefore, let first ingest it--which does patch#50515. All the best, simon PS: I disagree with your last statement. Because I am in favour for incremental improvements and not "The Right Thing or nothing". That's out of scope of the patch at hand. ;-) From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 06:10:27 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 10:10:27 +0000 Received: from localhost ([127.0.0.1]:47817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVWXi-0005AI-HW for submit@debbugs.gnu.org; Wed, 29 Sep 2021 06:10:27 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:38896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVWXg-0005A3-Kg for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 06:10:25 -0400 Received: by mail-wr1-f66.google.com with SMTP id u18so3296016wrg.5 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 03:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=XQOdtInPXisiBJUv1EnNzVh3xPp+ZK7ywnP+8ifqnLc=; b=URIFUSF3dHaNHszusAp1fK4/pOwPjTQB7mth3LdVE35k0GMBKrKwPuP2vvhfFoK3gw KWxH/3VWE/zjqHIT7ShACkjxTp7IsgGRHfm1IegLjI+P2eJhyBnf+jVVFZbH4iMGmCbl JBxFxcDxelLvIQWKqlghbwu38bTmYj4CsPdw5TLS2yEDHMMvP1ntQJoQ9MLQfEzH789v U8xBmKWbTraelkJCZpixjWHKRJ0nDNKlhTKkRwHy+Anmd8cd5hubMB5HjGtQJi8Xz22b mf5M+3gSR+W076aCiFMQHB1pln3+3O1BBBopdQpqfKcHqh333bfdGWSorDS4h08Yz7qF LNAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=XQOdtInPXisiBJUv1EnNzVh3xPp+ZK7ywnP+8ifqnLc=; b=cGzrWumYXp7iUV3BFC1ZaLJ093Ry7VhlCY80jf2VZdFpu8AIN+O+u5wnUWd7XTdMdW Bdo2NVCxA2ZUqbLwNszCDCgcHH9Z2wim6vlpGiOKfsotjo27rht14deStCPHENjaXc5U easa2xqIlVmvbBZajAlQ2JjAUFJ6s3hvZ0rYRVES2MUqb+Jy/BdvYJJ3vT4kZdwnwPlY XSoR1s0ngTe2jsor3FCGk+uKQtKKxPsYTsgMzSLBTdWgFjkBQrA5QeAk/aQqCpOKIjH7 ZxUMioJl9f34J/HBeAwWb0Bqc1ocqhMUq9ZPOgJs9f9VtA7q4bLM2WyEb9Lry8hRFhfL 5mSA== X-Gm-Message-State: AOAM533JSFHapZHdJngWtuvzizwrEP3V+7rijVfF+63YimnAW56+aTcL npyIhR/mPREnkDe5+7aOaCc= X-Google-Smtp-Source: ABdhPJyjXC5ATWEL21/sFreiPf+0UtE8yzatEBcG+zutZQrvWBiH0x/lWr6Zrq4vaHplIV4XjK/Adg== X-Received: by 2002:a5d:6644:: with SMTP id f4mr5769222wrw.231.1632910218551; Wed, 29 Sep 2021 03:10:18 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id d24sm1093899wmb.35.2021.09.29.03.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 03:10:18 -0700 (PDT) Message-ID: <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun Date: Wed, 29 Sep 2021 12:10:16 +0200 In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, Am Mittwoch, den 29.09.2021, 10:32 +0200 schrieb zimoun: > Hi, > > On Tue, 28 Sept 2021 at 19:24, Liliana Marie Prikler > wrote: > > > > Ok. I do not find it better than (guix packages) where 'origin' > > > is > > > defined but anyway. > > > I will send a v2 considering this and the rename you proposed. > > > > By that logic all of (guix git-download), (guix svn-download), etc. > > could be inlined there as well. Obviously that's a bad idea, but > > *why* is it a bad idea? I'd argue it's because we have a clear > > separation of the record descriptor for an origin and the ways it > > can be computed (the former in (guix packages), the latter > > elsewhere) and that it's good to keep those concerns separate. > > > > I also personally find the name "computed-origin" to be somewhat > > weird naming choice. I could just as well write the entire source > > code for some given package in the snippet part of an origin, > > perhaps applying some weird tricks in the category of Kolmogorov > > code golf – would that origin not be computed? > > Are we bikeshedding here? ;-) > > Again, the aim of this patch it not to fix the > 'computed-origin-method'. The aim of this patch is to improve the > readibility of the patch#50515 [1] which allows linux-libre and > icecat to be ingested by SWH from 'guix.gnu.org/sources.json'. > > Maybe there is an original issue with 'computed-origin-method', as > Mark explained [0]. But that's another story than the SWH and > sources.json one! Perhaps we're bikeshedding, but you started to shed the bike when you chose to move this procedure to (guix packages) rather than implementing one of Mark's suggestions in [0]. I do think we should allow for bikeshedding comments from both sides if that is the case. > [...] > > > > > it, but my main issue is that we still need to hide it! This > > > > will > > > > cause other channels to refer to it using @@ or roll their own > > > > implementations. > > > > > > This patch is not about discussing if this method should be > > > public or > > > not. It is private. Please discuss that elsewhere. > > > > > > Mark commented in [0]: > > > > > > --8<---------------cut here---------------start------------->8--- > > > The reason 'computed-origin-method' is not exported is because it > > > never went through the review process that such a radical new > > > capability in Guix should go through before becoming part of it's > > > public API. > > > --8<---------------cut here---------------end--------------->8--- > > > > > > and this patch is about improving the situation (by removing the > > > code > > > duplication). That's all. The aim of this improvement is > > > related to > > > saving these IceCat and Linux Libre packages by Software Heritage > > > [1]. > > > > I don't think delaying this review is a good idea, though. When > > you're removing code duplication, you ought to do it in a way that > > all duplicated code can indeed be removed, at least in my > > opinion. As-is this patch just invites practises otherwise > > discouraged by Guix. > > If you go this road, please push patch#50515 [1] as-is. It perfectly > works and fixes the issue with 'guix.gnu.org/sources.json' and SWH. > This current patch#50620 is a way to improve the readibility of > patch#50515 but then reading all this discussion I miss why > patch#50620 is thus a blocker for patch#50515. Because I feel we are > entering into the famous "Bigger problem" from xkcd. ;-) I don't think #50515 is "perfect as-is", though. Mark's (1) suggestion was to put computed-origin-method into its own module, which is the same as my long-term position. Mark suggested a short-term fix (2) of still comparing by eq?, which I believe you dismissed for the wrong reasons. Yes, you would still need to check the promise, but you wouldn't invert said check, i.e. you would still first look for the method and then assert that the uri makes sense. I think it is safer to err on the side of conservatism here rather than claim that this code will work for future computed-origin-esque methods. Instead of doing either (1) or (2), you opted for your own solution (3), which is to put this method into (guix packages). In my personal opinion, this is a half-baked solution, because it puts computed- origin-method into the (guix ...) without addressing any of the more fundamental issues raised by Mark. If you really, really can't put this into its own module, then I'd at least suggest (3a), which is to put it into (gnu packages) instead. That way, the definition is at least closer to where it's used and it's clearer that it's a hack to package certain things, not a core part of Guix. Perhaps you can even make use of it without needing to rebuild the guix package in [2/2], but don't quote me on that. > Patch#50515 is the first part of a concrete answer to > > and < > https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00290.html>; > . > It is discussed to use SWH for such situations but today our > linux-libre is not ingested by SWH. Therefore, let first ingest > it--which does patch#50515. > > All the best, > simon > > PS: I disagree with your last statement. Because I am in favour for > incremental improvements and not "The Right Thing or > nothing". That's out of scope of the patch at hand. ;-) Perhaps you are right in that we can't wait for a lengthy discussion of whether computed-origin-method can be public (guix) API or not. Either way, it does not look as though this thread attracts enough attention to that issue, which is why we can ignore Mark's option (1) for now. For the right amount of incremental change, I'd suggest the following: Try to see whether you can do with computed-origin-method in (gnu packages) and without rebuilding the guix package, and if so, submit a v2 to #50515, which implements that. Otherwise, submit a v2 to #50515 that implements Mark's option (2). If you are also interested in the more long-term discussion of allowing computed origins into the (guix) tree, I suggest sending a v2 patch to this thread, which creates a new module, adds documentation, and so on, and so forth, and also link to it on guix-devel. For the time being, this v2 should also refrain from touching anything that uses the current computed-origin-method, as that can be addressed in rather simple follow-up commits, particularly if we also implement a #50515-v2 before. Then we can fully use this to bikeshed about making it a verb and what not. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 09:16:55 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 13:16:55 +0000 Received: from localhost ([127.0.0.1]:48066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVZSB-0001uA-0l for submit@debbugs.gnu.org; Wed, 29 Sep 2021 09:16:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVZS9-0001tw-H2 for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 09:16:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56074) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVZS3-0004MQ-DQ; Wed, 29 Sep 2021 09:16:47 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=36416 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVZRa-0003tO-Rw; Wed, 29 Sep 2021 09:16:19 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mark H Weaver 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> Date: Wed, 29 Sep 2021 15:16:16 +0200 In-Reply-To: <87pmstghx0.fsf@netris.org> (Mark H. Weaver's message of "Tue, 28 Sep 2021 05:36:48 -0400") Message-ID: <87a6jv8qu7.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: Liliana Marie Prikler , 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 there! I=E2=80=99d rather go with zimoun=E2=80=99s original patch, which is focuse= d and does nothing more than what was originally intended, which is to factorize the procedure. I=E2=80=99ll go ahead and apply it shortly if there are no objections. As Mark wrote, =E2=80=98computed-origin-method=E2=80=99 remains a hack, so = we can discuss about the best way to improve on it, but that=E2=80=99s a separate discussion. What you propose, Liliana, is one possible way to improve on the situation, but only on the surface: the hack remains, it just gets its own module. A better solution IMO would be to improve the =E2=80=98snippet=E2=80=99 mec= hanism in the first place. =E2=80=98computed-origin-method=E2=80=99 improves on it in tw= o ways: (1) lazy evaluation of the gexp, and (2) allows the use of a different base name. I would think #2 is addressed by the =E2=80=98file-name=E2=80=99 field (isn= =E2=80=99t it?). As for #1, it can be addressed by making the =E2=80=98snippet=E2=80=99 fiel= d delayed or thunked. It=E2=80=99s a one line change; the only thing we need is to meas= ure, or attempt to measure, the impact it has on module load time. Thoughts? Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 09:17:34 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 13:17:34 +0000 Received: from localhost ([127.0.0.1]:48070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVZSo-0001vX-9I for submit@debbugs.gnu.org; Wed, 29 Sep 2021 09:17:34 -0400 Received: from mail-qv1-f54.google.com ([209.85.219.54]:36468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVZSi-0001vE-Ph for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 09:17:32 -0400 Received: by mail-qv1-f54.google.com with SMTP id jo30so1417406qvb.3 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 06:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oX4U24EgJxf3a/X88JZ6ful5kvXu+m67M3u51iKaE8M=; b=REzmL5Fc/hgfMGfBqfGGHSwm0pZTwlR+xRsuSl0bxnWoAiRwajjwDvkPn/ERpXvho1 SwLt9f0ZLyxjeZ6cSexl+NlkpuqFCCIDdwdVB7j4biFJxHZbdGtn6huvE3HJ7/uMCZMo e3VOWziEXVhtFN+o2abXL3FngNSeOPSisIC0FP5qrCA1Y5AZ2bDyXzuj7R5X+qsJnb+N WOJFtwFs8KcJYfJUTyrDrqvcvlPG4GIVi9cv/heGiw4cft115Medxle6VsfCbr5faF/k oHxHaLSdeebt2/6vHJZklEqGh3yt3fcDhPXZh8VjsJnF0s8Tdy6RVGv2AQaYeQ3flpXU hrpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oX4U24EgJxf3a/X88JZ6ful5kvXu+m67M3u51iKaE8M=; b=PyK3ZScErBKw88l8QsHxMwLdk+LtJIC0wAVbARqRD0zLBSJ3eLga4IKHFsx7y+1mI+ Np8B0zIvU8AGaS4VjsdCsFdUetpwEFhq5/lVUVhjAKgRFeizpCr9oNtEsdhbuLctxyHu p3vVAQ4n3vfOJ7N3Z+5VIHxhqhi1sp3bDzXl+mSzwEaAL/f1zpCy95bD8HBmfADijPp4 eIgG4JDTCi1xp+9UUbzh5R4kEpAFdYATzmv2hoNUh6FBkxOjPzxhjRDpsE75WcYltKXf dXyA0m4SrtM52eFbIMxET70Lx1cYheoI3d2wKtphQgbBr2BZ2jfVMScQoANtgRSB8Nrs MZYQ== X-Gm-Message-State: AOAM532tCGZPqHtaARculOKaXPOtF2aVyK1vfRdTW7+GemWsMJXwgTBg EPAHGeJR0BdO4WLpeeHiSeRZo3YCh7b536x5ZqU= X-Google-Smtp-Source: ABdhPJxbg6mA+CDGhbi7Umpn1uOL+/TEzN7xKxAcZQM6tNVY++kUNolY2u1ziAvPGDK8DZVMO9FrojRu2MBSH0+DyPE= X-Received: by 2002:ad4:484a:: with SMTP id t10mr2943648qvy.55.1632921442215; Wed, 29 Sep 2021 06:17:22 -0700 (PDT) MIME-Version: 1.0 References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> In-Reply-To: <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> From: zimoun Date: Wed, 29 Sep 2021 15:17:10 +0200 Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. To: Liliana Marie Prikler Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, On Wed, 29 Sept 2021 at 12:10, Liliana Marie Prikler wrote: > Perhaps we're bikeshedding, but you started to shed the bike when you > chose to move this procedure to (guix packages) rather than > implementing one of Mark's suggestions in [0]. I do think we should > allow for bikeshedding comments from both sides if that is the case. I do not have time to bikeshed. :-) (Even if I like to practise it. ;-)) (Note that Mark agreed on my proposal as a variant of one of their suggestions [0].) 0: > I don't think #50515 is "perfect as-is", though. Mark's (1) suggestion > was to put computed-origin-method into its own module, which is the > same as my long-term position. Mark suggested a short-term fix (2) of > still comparing by eq?, which I believe you dismissed for the wrong > reasons. Yes, you would still need to check the promise, but you > wouldn't invert said check, i.e. you would still first look for the > method and then assert that the uri makes sense. I think it is safer > to err on the side of conservatism here rather than claim that this > code will work for future computed-origin-esque methods. Maybe. Well, I commented there [1], reworded here: The option (1) with its own module means make computed-origin-method public which implies a lengthy discussion, therefore it is not an option for me. We agree an option (1), I guess. ;-) From my point of view, the long-term solution is to improve snippet and remove this computed-origin-method; not make it public. Perhaps I am wrong about option (2) -- my claim is that computed-origin-method is *always* used with a promise so it is for sure an half-baked guess but enough; and it avoids to hard code the modules from where the packages come from. Therefore, option (2) does not improve, IMHO. For sure, I am right about this [1]: --8<---------------cut here---------------start------------->8--- However, I would not like that the sources.json situation stays blocked by the computed-origin-method situation when sources.json is produced by the website independently of Guix, somehow. :-) --8<---------------cut here---------------end--------------->8--- because it is exactly what it is: blocked by the computed-origin-method situation. 1: > Instead of doing either (1) or (2), you opted for your own solution > (3), which is to put this method into (guix packages). In my personal > opinion, this is a half-baked solution, because it puts computed- > origin-method into the (guix ...) without addressing any of the more > fundamental issues raised by Mark. If you really, really can't put > this into its own module, then I'd at least suggest (3a), which is to > put it into (gnu packages) instead. That way, the definition is at > least closer to where it's used and it's clearer that it's a hack to > package certain things, not a core part of Guix. Perhaps you can even > make use of it without needing to rebuild the guix package in [2/2], > but don't quote me on that. All the solutions are half-baked! :-) Also, generating this sources.json using the website is half-backed at first. ;-) Options (1) and (2) are more half-baked than my initial submission (3) (guix packages) or (3a) (gnu packages), IMHO. I still think that (guix packages) is better than (gnu packages). Maintainers, what do you think? About update guix package [2/2], it has to be done, IIUC. The file sources.json contains what the package guix provides, not what the current Guix has. The website -- built using the Guile tool haunt -- uses Guix as a Guile library. Maybe I miss something. > For the right amount of incremental change, I'd suggest the following: > Try to see whether you can do with computed-origin-method in (gnu > packages) and without rebuilding the guix package, and if so, submit a This is what I suggested earlier ;-) [2]: send a v2 moving to '(gnu packages)' instead and rename to 'compute-origin'. Although I disagree on (gnu packages). :-) I need explanations if rebuild the guix package is not necessary. 2: > If you are also interested in the more long-term discussion of allowing > computed origins into the (guix) tree, I suggest sending a v2 patch to > this thread, which creates a new module, adds documentation, and so on, > and so forth, and also link to it on guix-devel. For the time being, > this v2 should also refrain from touching anything that uses the > current computed-origin-method, as that can be addressed in rather > simple follow-up commits, particularly if we also implement a #50515-v2 > before. Then we can fully use this to bikeshed about making it a verb > and what not. For long-term, the road seems to improve the 'snippet' mechanism, not make computed-origin-method public, IMHO. All the best, simon From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 10:36:58 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 14:36:58 +0000 Received: from localhost ([127.0.0.1]:49774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVahd-0004ND-LJ for submit@debbugs.gnu.org; Wed, 29 Sep 2021 10:36:58 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:37577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVahS-0004Mb-AP for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 10:36:47 -0400 Received: by mail-wm1-f67.google.com with SMTP id r83-20020a1c4456000000b0030cfc00ca5fso5491234wma.2 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 07:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=hp3EsMoBt1CMz4OdqaDHj9Krv1cJBZJqUmegGHoMyQ0=; b=D+VAgiQA2VN7CY+BxIKYq18aWIjOSFg/4brWZCe1OSnc5UCVNUu+EcOoEQAD/feqR+ AyTdHbIqImDgGEdqLinz+xfQmB6UDr7kgZuTnC16K0ZeeE+nQgMDgitYwhCMWxsVqS7M qSdlqXef9zogwaZxGqaF16HXGPXRZ8Xow6dEKfgPqACFoR5lxtOsftmcidKH7POwKPbZ W/fk2WxKep8cvVqp4/WmnPd739c0Hokt6yzM8jb5CRO6GH9x0sLIJAZHzXRsNdKDXtNf +J9PmWU0/0KaXU1NS4Gm+Ekb/uCnKRFfr+oXBsyhZmAFCcPsIfOSHNKTzvW1YjCld5Es Bz9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=hp3EsMoBt1CMz4OdqaDHj9Krv1cJBZJqUmegGHoMyQ0=; b=Pl5y0s2mLDAlE+n1XaaxHXY7sXbLMVLHkF8cK1MVbhMrsYRW6eqB9mT9PKa2OU4UUA auVfE9K1cN0xUgRZtvBonfunjsrk5dtIGEGya6M1tO4q1zfhURCS7eXC4CItWnZNDHTC pFhNp7d0oRo/1IrwsbOHX+JVnvm3eJRvcaD+82ZIdrQaKfePCpYpXt4EqA5EkEQfNc0B qfAkqGZjxrg0Y91FXJZkgUDw8+1oyGtOzoh2HrEO+qQKrWR0DxrfvMYabsehvyIgl1jk RXNo4q7JJquGp6HBs7LJBgit/SwN5Ck63xCnKQv3JlWREyFQ4tmdtoUtojGyXsLirycl fEbg== X-Gm-Message-State: AOAM530INWsGMIo2sBrNHlKcLXgiEX++7G24uKSG0XfpeShPZFl/Geam aN33kHdB2bXT1SVE+2tuDFg= X-Google-Smtp-Source: ABdhPJwJG3dJJjNI6SuE3QdsQov9RuSAE7exeewQK8oAaFuCIzpECpsmkJJAQJwsJe4+4lxgOlVu1Q== X-Received: by 2002:a7b:c391:: with SMTP id s17mr10905092wmj.139.1632926200226; Wed, 29 Sep 2021 07:36:40 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id t11sm68012wrz.65.2021.09.29.07.36.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 07:36:39 -0700 (PDT) Message-ID: <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun Date: Wed, 29 Sep 2021 16:36:38 +0200 In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, Am Mittwoch, den 29.09.2021, 15:17 +0200 schrieb zimoun: > Hi, > > On Wed, 29 Sept 2021 at 12:10, Liliana Marie Prikler > wrote: > > > Perhaps we're bikeshedding, but you started to shed the bike when > > you chose to move this procedure to (guix packages) rather than > > implementing one of Mark's suggestions in [0]. I do think we > > should allow for bikeshedding comments from both sides if that is > > the case. > > I do not have time to bikeshed. :-) (Even if I like to practise it. > ;-)) > > (Note that Mark agreed on my proposal as a variant of one of their > suggestions [0].) > > 0: While Mark did agree to that, I still think that (guix packages) is the wrong location for this procedure. Multiple reviewers can hold different opinions on that matter. > > I don't think #50515 is "perfect as-is", though. Mark's (1) > > suggestion was to put computed-origin-method into its own module, > > which is the same as my long-term position. Mark suggested a > > short-term fix (2) of still comparing by eq?, which I believe you > > dismissed for the wrong reasons. Yes, you would still need to > > check the promise, but you wouldn't invert said check, i.e. you > > would still first look for the method and then assert that the uri > > makes sense. I think it is safer to err on the side of > > conservatism here rather than claim that this > > code will work for future computed-origin-esque methods. > > Maybe. Well, I commented there [1], reworded here: > > The option (1) with its own module means make computed-origin-method > public which implies a lengthy discussion, therefore it is not an > option for me. We agree an option (1), I guess. ;-) From my point > of view, the long-term solution is to improve snippet and remove this > computed-origin-method; not make it public. I personally think there are certain cases where it would make sense to compute origins, but they are not widely applied because computed- origin-method is hidden and clunky. For instance, there are several packages, that pull in extra origins as inputs, which could however be argued to be part of the source closure. Again, there is room to bikeshed far and wide here and all we can agree to currently is that we need some solution long-term. > Perhaps I am wrong about option (2) -- my claim is that > computed-origin-method is *always* used with a promise so it is for > sure an half-baked guess but enough; and it avoids to hard code the > modules from where the packages come from. Therefore, option (2) > does not improve, IMHO. The probability of having a promise when using computed-origin-method is 100%. What is the probability of having computed-origin-method when you see a promise? The answer is: we don't know. We can see from the existing two copies of computed-origin-method, that they use promises, but you could imagine an origin method that takes a promise only as part of its input and then transforms it in some way under the hood. You could also imagine a different computed-origin-method that is actually thunked or uses a raw gexp. > For sure, I am right about this [1]: > > --8<---------------cut here---------------start------------->8--- > However, I would not like that the sources.json situation stays > blocked by the computed-origin-method situation when sources.json is > produced by the website independently of Guix, somehow. :-) > --8<---------------cut here---------------end--------------->8--- > > because it is exactly what it is: blocked by the > computed-origin-method situation. > > 1: Sure, I agree that we need to divorce these discussions if this one is going to take longer – which from the looks of it, it is. > > Instead of doing either (1) or (2), you opted for your own solution > > (3), which is to put this method into (guix packages). In my > > personal opinion, this is a half-baked solution, because it puts > > computed-origin-method into the (guix ...) without addressing any > > of the more fundamental issues raised by Mark. If you really, > > really can't put this into its own module, then I'd at least > > suggest (3a), which is to put it into (gnu packages) instead. That > > way, the definition is at least closer to where it's used and it's > > clearer that it's a hack to package certain things, not a core part > > of Guix. Perhaps you can even make use of it without needing to > > rebuild the guix package in [2/2], but don't quote me on that. > > All the solutions are half-baked! :-) Also, generating this > sources.json using the website is half-backed at first. ;-) > > Options (1) and (2) are more half-baked than my initial submission > (3) (guix packages) or (3a) (gnu packages), IMHO. I don't think option (1) is half-baked, but it does entail making computed-origin-method somewhat public API, which would need more careful review than initially assumed. (2) is half-baked indeed, but because it is minimal effort. Instead of touching the modules in which the definitions are made, it just references them. > About update guix package [2/2], it has to be done, IIUC. The file > sources.json contains what the package guix provides, not what the > current Guix has. The website -- built using the Guile tool haunt -- > uses Guix as a Guile library. Maybe I miss something. What I was trying to say was that you wouldn't need to rebuild the guix package before applying the 50515 changes, which this one seems to require. Again, I'm not 100% sure that's the case, but IIUC (gnu packages) is its own realm in this regard. > > For the right amount of incremental change, I'd suggest the > > following: Try to see whether you can do with computed-origin- > > method in (gnu packages) and without rebuilding the guix package, > > and if so, submit a > > This is what I suggested earlier ;-) [2]: send a v2 moving to '(gnu > packages)' instead and rename to 'compute-origin'. Although I > disagree on (gnu packages). :-) > > I need explanations if rebuild the guix package is not necessary. > > 2: I don't think a rename is necessary if we want a "quick and dirty" version, this suggestion was rather made in the intention that it would be public API. However, if you like the naming choice, feel free to apply it. > > If you are also interested in the more long-term discussion of > > allowing computed origins into the (guix) tree, I suggest sending a > > v2 patch to this thread, which creates a new module, adds > > documentation, and so on, and so forth, and also link to it on > > guix-devel. For the time being, this v2 should also refrain from > > touching anything that uses the current computed-origin-method, as > > that can be addressed in rather simple follow-up commits, > > particularly if we also implement a #50515-v2 > > before. Then we can fully use this to bikeshed about making it a > > verb and what not. > > For long-term, the road seems to improve the 'snippet' mechanism, not > make computed-origin-method public, IMHO. I do have some opinions on that, but I'll type them out in response to Ludo, so as to not repeat myself too often. Cheers From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 11:34:36 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 15:34:37 +0000 Received: from localhost ([127.0.0.1]:49899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVbbQ-0001sj-Hd for submit@debbugs.gnu.org; Wed, 29 Sep 2021 11:34:36 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:46891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVbbO-0001sV-Tf for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 11:34:35 -0400 Received: by mail-wr1-f65.google.com with SMTP id k7so4899521wrd.13 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 08:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=PK096D43xDcLy+DzKfOxvd78xfKN7lQh7bRaYqlWSlk=; b=ckjZofuqp3yHG+dIdxdLUU67o30MUifVRH9Y+1/92QAdtpOTCK3+WOK8AnhkPl80q1 vfa90Jl+iir9vwfE3LQR6+mYOTPbvV1lGsJLGjGufEiGG86+lOkk6XjlNuJkek3EcUqy uBFwxIpwvJOg3F1wgbWtn11azU4uhwZlh63Tr1W939PctweuRsLHCZadMC0WyJGRjxBS MHNIce1XUJy//l7GAlT0+Rk2HCuWd0UefI8Jgr0jUnKPAdJGx9IHcBwe0Tn1JDBpUCBW qIMIqSHcAy2+AFCUK3QCXiMoyL5RX2cnNyXJucPJZ68DcY0TLPa7Yw+Y9jLCvMG1A6tN bkZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=PK096D43xDcLy+DzKfOxvd78xfKN7lQh7bRaYqlWSlk=; b=jp5kO1lACDrlYPLiL8YOuB6AvpWl/2uogRN+cP4sFvaKIuZz2re+tdvAHeH/Ivjsgj iVjfBa5xrKwA6UxLTiAgGiSAVnF7qVMnBCpBLgvCYto5KvFZ5XsvmFtLFVZb4hY6Wd0N IMgSoqiV0/QJAVIyiheghmR6Yh6/LGfwZInodH+d3A2ePZaxAs+RJ8cmfliwh7SGoYMg 1MIzYDdicKMtIqoUn/sWpYNiECbs0Ut9ojPzVwxJWjwvXSMtSoROEKLCVPj+UJrOW9bg SAN6dFa5DdV6iFLEd9NNYgykIjL/J0+4Z2egBUfX5yavtROc8CAW43L4o1eXrLmhnh4h Cw8g== X-Gm-Message-State: AOAM5317n/XnLsel8JAtHvll3Gd900QfxlhvSOgouJ56idQOrfIpqwLj rHUYGyZt37lhXJ7dAOgLseg= X-Google-Smtp-Source: ABdhPJyzn74BxRxccc9iyK+vjLFZHsXwV1Ttxj5S8nd18Yvecnh9rZedGxtsb40CtRwOdb+qGNZ4jw== X-Received: by 2002:adf:e509:: with SMTP id j9mr604155wrm.416.1632929668813; Wed, 29 Sep 2021 08:34:28 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id u3sm168908wmc.16.2021.09.29.08.34.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 08:34:28 -0700 (PDT) Message-ID: Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) From: Liliana Marie Prikler To: Ludovic =?ISO-8859-1?Q?Court=E8s?= , Mark H Weaver Date: Wed, 29 Sep 2021 17:34:27 +0200 In-Reply-To: <87a6jv8qu7.fsf_-_@gnu.org> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <87a6jv8qu7.fsf_-_@gnu.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 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: -1.0 (-) Hi there, Am Mittwoch, den 29.09.2021, 15:16 +0200 schrieb Ludovic Courtès: > Hi there! > > I’d rather go with zimoun’s original patch, which is focused and does > nothing more than what was originally intended, which is to factorize > the procedure. I’ll go ahead and apply it shortly if there are no > objections. I have trouble understanding this paragraph. What exactly is "this patch" and what do you mean by "factorizing"? If it means moving computed-origin-method elsewhere, then yes, for a short-time solution only moving it is a wise choice in my opinion, but zimoun and I still disagree on the target. zimoun says (guix packages) for reasons unknown to me, whereas I say (gnu packages), because it's closer to where it's used and doesn't imply that this is going to be a part of the (guix) download schemes anytime soon. > As Mark wrote, ‘computed-origin-method’ remains a hack, so we can > discuss about the best way to improve on it, but that’s a separate > discussion. What you propose, Liliana, is one possible way to > improve on the situation, but only on the surface: the hack remains, > it just gets its own module. I don't necessarily perceive computed-origin-method as a hack, though, at least not in concept. The current implementation may be a hack indeed, but I don't think the very concept of expressing an input as a function is. We are functional programmers after all :) > A better solution IMO would be to improve the ‘snippet’ mechanism in > the first place. ‘computed-origin-method’ improves on it in two > ways: (1) lazy evaluation of the gexp, and (2) allows the use of a > different base name. > > I would think #2 is addressed by the ‘file-name’ field (isn’t it?). > > As for #1, it can be addressed by making the ‘snippet’ field delayed > or thunked. It’s a one line change; the only thing we need is to > measure, or attempt to measure, the impact it has on module load > time. > > Thoughts? This would work for packages, whose source are some base source with patches or snippets applied, as is indeed the case for linux and icecat. However, there are also other potential uses for computed origins. Grepping for the string "'unpack 'unpack", which indicates that more sources are unpacked at build-time returns more than fifty instances in a number of locations. This is potentially dangerous, as for one, we will probably want to phase out the "origins as inputs" idiom once we have short-form inputs and also it could be argued, that `guix build -S` returns something wrong in those packages. I think that some version of `computed-origin-method' will eventually need to become public API as such packages may not always be best described as "a base package with a snippet". If we had recursive origins – i.e. origins, that can take origins as inputs – we might be able to do some of that, but I don't think it would necessarily work for linux-libre or icecat, as with those you don't want the tainted versions to be kept around. Perhaps this could be worked around by not interning the intermediate origins, but only using their file-names inside the temporary directory in which the snippet is applied? Another thing is that the final act of the linux-libre promise is not the packing of the tarball, but the deblob-check. Guix currently lacks a way of modeling such checks in their origin, but I'd argue it would need one if we wanted to do computed origins via snippets. This is not required by icecat and so one "simplification" could be that computed- origin-method would not require the user to create a tarball, but instead simply provide a name for the tarball and a directory to create it from (via a promise again). 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 13:49:14 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 17:49:14 +0000 Received: from localhost ([127.0.0.1]:50138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVdhi-000899-98 for submit@debbugs.gnu.org; Wed, 29 Sep 2021 13:49:14 -0400 Received: from mail-qv1-f42.google.com ([209.85.219.42]:40869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVdhS-00088K-8y for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 13:49:13 -0400 Received: by mail-qv1-f42.google.com with SMTP id n6so1955378qvp.7 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 10:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tdMberHwvY0JM31+/fr51iEKsYqdl8r6OOnwPHMzE04=; b=GIa+Mex/NlnhmCg97FCrSfQdiNdzGtsFr2RreiUX/T9HL68RrbRK4wsn6ht15lyF5o 6eux7Kw4eDk4pEZe1mXXcYpu/Eor0MBm/uYCgeKxCxmFlhtIulCzcq9ewabvMUx7Ecr+ kD+++pWvbUo2TSwNcDvwWxTE7in4DMhV1US9NOTkh4Aiwi0phJkXyDjE9Ut0tRVN+Ek2 mU4ZpOsXStqbfMd5674KXj/IK1jzKhZ3iKpMY10LDXkt4VwxAAkvk3Q4wTUGtyyMehax jft1n2PTTkwmh9Mhk4q6oDZ7KVI1Cj0mLH/zFSzNm/SGNmcKjwWCY8dciPRJf1h8J5/5 APYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tdMberHwvY0JM31+/fr51iEKsYqdl8r6OOnwPHMzE04=; b=VWFaar4XaYC7AAZ+AJ+kiX+5ewknAV4NruXzBXGHhhId5neDffIygNzuSCpKmwOf0M JyZlEsqDsfxYGKu++GqjRC/RJ0j7h0GbjxZxQyiESMxwSrNc2tFo226HtRClWx+kB4pv 5I8EHv0/E/o9JP69d/RmwvJRGPkv7glVICrnEufXZnP5HoNuqoHpAKaU7or9cdKVbtlE aPSrpCru6vrZrRK22z6jrf0UwuUDhFaqOEnJd8IoAJE1Vhil7hYBmnGpuZY6w6/rsj+Y yeRKwX2C5bO1SSWvLRkAST5Wrzp54KxfZ6hnWz26a0l6dla9gW6YPCNw49Kk3HW2Qct6 AQvQ== X-Gm-Message-State: AOAM533cMJJPzWQQkS9/5km2N+INpigx3K+fwr1vggM8MYrTC0rWNwWU OsPvae14bjoyZreieqf52i3l1q44LwJRtT21l4pEj24LPqE= X-Google-Smtp-Source: ABdhPJzqX5k2Opj6EfPqrDXU0LmQNnfCvfaWmCY7v2x4dfzCmqDH2FYqbvjgTMdKstTOuGe70j38eg1iCY2cUl6p6E4= X-Received: by 2002:a05:6214:1425:: with SMTP id o5mr1271468qvx.5.1632937732676; Wed, 29 Sep 2021 10:48:52 -0700 (PDT) MIME-Version: 1.0 References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> In-Reply-To: <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> From: zimoun Date: Wed, 29 Sep 2021 19:48:41 +0200 Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. To: Liliana Marie Prikler Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, On Wed, 29 Sept 2021 at 16:36, Liliana Marie Prikler wrote: > > Perhaps I am wrong about option (2) -- my claim is that > > computed-origin-method is *always* used with a promise so it is for > > sure an half-baked guess but enough; and it avoids to hard code the > > modules from where the packages come from. Therefore, option (2) > > does not improve, IMHO. > > The probability of having a promise when using computed-origin-method > is 100%. What is the probability of having computed-origin-method when > you see a promise? The answer is: we don't know. We can see from the You mean, what is the probability of having a computed-origin-method when the origin-uri is a promise? We do not know, but pragmatically, for now 100%. :-) Option (2) is: ___ (or (eq? method (@@ (gnu packages gnuzilla) computed-origin-method)) _______ (eq? method (@@ (gnu packages linux) computed-origin-method))) then I ask you similarly: what is the probability of having packages using computed-origin-method in these 2 modules only? We do not know, but pragmatically, for now 100%. :-) The hypothetical probabilities to evaluate are: - what would be the probability that a new package having a promise as origin-uri is not indeed a package with a computed-origin-method? vs - what would be the probability that a new package using computed-origin-method is not part of either (gnu packages gnuzilla) or (gnu packages linux)? Anyway! Well, I am not convinced that it is worth to tackle these hypothetical issues. :-) That's why the option (3): (eq? method (@@ (guix packages) computed-origin-method)) which means refactorize*. It is somehow the two worlds: check i.e., safer, no modules hard-coded and keep private the time to have The Right Plan for this computed-origin-method. *refactorize: I think (guix packages) is better because it defines '' and other tooling friends. Because 'computed-origin-method' is somehow a temporary tool about origin, i.e., a mechanism to define packages, it makes sense to me to put it there. However, (gnu packages) is about tools to deal with packages, not to define them; although one could argue that 'search-patch' is there is used to define package. For what my rationale behind the choice of (guix packages) is worth. And indeed, I have only half-mentioned this rationale. As I said, generating this sources.json file by the website is clunky. Somehow, it is a quick hack to have something up waiting The Right Way; the long-term generations should be done through the Data Service, as it had been already discussed but not yet implemented. Help welcome. :-) > > About update guix package [2/2], it has to be done, IIUC. The file > > sources.json contains what the package guix provides, not what the > > current Guix has. The website -- built using the Guile tool haunt -- > > uses Guix as a Guile library. Maybe I miss something. > > What I was trying to say was that you wouldn't need to rebuild the guix > package before applying the 50515 changes, which this one seems to > require. Again, I'm not 100% sure that's the case, but IIUC (gnu > packages) is its own realm in this regard. Hum, maybe there is a misunderstanding here. On one hand 50620 applies to the guix.git repo and on the other hand 50515 applies to guix-artwork.git repo. To have the sources of linux-libre and icecat reported in sources.json and thus to get a chance to have them archived by SWH, we need: a- if computed-origin-method is factorized then update the guix package (Guix as a library) else do nothing; patch applied to guix.git b- tweak how sources.json is built; patch applied to guix-artwork.git Well, the aim of 50620 is to deal with a) whereas the aim of 50515 is to deal with b). Note that 50515 requires a v2 if computed-origin-method is factorized. Maybe I miss something. From my understanding, all the modules are part of Guix as a library. Therefore, it does not depends on where we refactorize. To be honest, I thought that this tiny improvement of the SWH coverage would have been much more easier and that that trivial task would not have taken more than 15 days with lengthy discussions. :-) > I do have some opinions on that, but I'll type them out in response to > Ludo, so as to not repeat myself too often. Thanks. I will comment overthere or maybe raise the discussion to guix-devel. All the best, simon From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 15:10:55 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 19:10:55 +0000 Received: from localhost ([127.0.0.1]:50270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVeyk-0001vr-K1 for submit@debbugs.gnu.org; Wed, 29 Sep 2021 15:10:55 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:41721) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVeyh-0001va-IE for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 15:10:53 -0400 Received: by mail-wm1-f68.google.com with SMTP id g19-20020a1c9d13000000b003075062d4daso2519328wme.0 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 12:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=/rF2ZpWoz5okrdZI5+WyqU3igx44TfO4VAxxv/wl8qc=; b=kNglubXCRPg/UvyjrXbqy7YOnn0si4UGUSpsmwEjc9yVxuViRMb6ly4TAdhRKrbf8E PWdjDgziFsoePyfPqa+GwlAQZHhGilSSfYWtOfdij8ez4VYW/DwD9T0CRdC4Y00N+idh SKdePpY7bPa2sugVQDWUnUwJ28uKHXWOvdIghSrnkXCnzSwWWtExoqc89eoABSeIYluh r7KGN8yUbsPkSnvheNZ5lMhG+Pe0shSNnI1HPhf+2vT7XKN2ja2pfAAmsol0ff316n/z 5qCcdNPIub6yihLk7GgV4GWfZjZwgijS17xyEwXSP47CQO0KsBEUEqvPKIF9avwDv3LG Q1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/rF2ZpWoz5okrdZI5+WyqU3igx44TfO4VAxxv/wl8qc=; b=KbioswspTBTcip50GUPrtDCNpTnoRrhzvH+B4bPzLx/ycOAZPWTvCUbjecoX2CuBL3 6nuEvFKMXskqmQ0nEUkPe0VJYePqLUtrZAAGfk0hO896C7GACsCUnx8zn3J7Fo6oLwtj 3UrcU0f0ucNG1TKr1KRjX/sIzEKZ7u/DIHE6Ge28VLA0D8ZS+TusO4CLpW3YUiFDZAsh vc8M2js/2IVz579Yf3KF/IBa6Yd3339ScmNZAejoPqOpMkMH3UzT8baLdBuU1GerNiIO xBdPQ2ZjBtPatShNI9c4XRgMqQekz5uh/f4KJZuZM6OxedJ/HT4h/4EHl/DS2vkckkl1 47VA== X-Gm-Message-State: AOAM5303Hz04JcZ/gsn3xDvZwQkXt4/1d1e4D841ztSW+j+bQU4W/zAV Rro6rPzpt9LMgJk3A8st77Y= X-Google-Smtp-Source: ABdhPJyF+9hxNuFFzGou9NM6LtFt+NkygoMV8qGs6/VqNKOQPALr7Od8+mT0b8Lp5Ald6pwq25Q+nw== X-Received: by 2002:a1c:2082:: with SMTP id g124mr837300wmg.192.1632942645628; Wed, 29 Sep 2021 12:10:45 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id m29sm714735wrb.89.2021.09.29.12.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 12:10:45 -0700 (PDT) Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun Date: Wed, 29 Sep 2021 21:10:43 +0200 In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, Am Mittwoch, den 29.09.2021, 19:48 +0200 schrieb zimoun: > Hi, > > On Wed, 29 Sept 2021 at 16:36, Liliana Marie Prikler > wrote: > > > > Perhaps I am wrong about option (2) -- my claim is that > > > computed-origin-method is *always* used with a promise so it is > > > for sure an half-baked guess but enough; and it avoids to hard > > > code the modules from where the packages come from. Therefore, > > > option (2) does not improve, IMHO. > > > > The probability of having a promise when using computed-origin- > > method is 100%. What is the probability of having computed-origin- > > method when you see a promise? The answer is: we don't know. We > > can see from the > > You mean, what is the probability of having a computed-origin-method > when the origin-uri is a promise? We do not know, but pragmatically, > for now 100%. :-) > > Option (2) is: > > ___ (or (eq? method (@@ (gnu packages gnuzilla) computed-origin- > method)) > _______ (eq? method (@@ (gnu packages linux) computed-origin- > method))) > > then I ask you similarly: what is the probability of having packages > using computed-origin-method in these 2 modules only? We do not > know, > but pragmatically, for now 100%. :-) > > The hypothetical probabilities to evaluate are: > > - what would be the probability that a new package having a promise > as origin-uri is not indeed a package with a computed-origin-method? > vs > - what would be the probability that a new package using > computed-origin-method is not part of either (gnu packages gnuzilla) > or (gnu packages linux)? > > Anyway! Well, I am not convinced that it is worth to tackle these > hypothetical issues. :-) I meant that only in reference to a comparison of your original patch in #50515 vs. option (2). Option (2) is conservative, it only detects computed origin which it knows how to handle. Your original patch is more liberal in that it detects anything that has a promise as uri as a computed origin, which might however not have the same semantics as those two copies of the same code. Obviously, both (3) and (3a) don't have this problem, but they're also conservative in that e.g. I could roll my own channel with the exact same computed-origin-method copypasta'd once more and it wouldn't be detected, though that's probably off-topic.[1] > That's why the option (3): > > (eq? method (@@ (guix packages) computed-origin-method)) > > which means refactorize*. It is somehow the two worlds: check i.e., > safer, no modules hard-coded and keep private the time to have The > Right Plan for this computed-origin-method. I was a little confused when I read factorize from Ludo or refactorize from you. I know this technique under the name "refactoring". > *refactorize: I think (guix packages) is better because it defines > '' and other tooling friends. Because > 'computed-origin-method' is somehow a temporary tool about origin, > i.e., a mechanism to define packages, it makes sense to me to put it > there. However, (gnu packages) is about tools to deal with packages, > not to define them; although one could argue that 'search-patch' is > there is used to define package. For what my rationale behind the > choice of (guix packages) is worth. And indeed, I have only > half-mentioned this rationale. To that I would counter, that (guix packages) only defines package and origin records and how to compile them to bags and derivations. All the methods through which those fields are filled are defined outside, be it the occasional local-file used in "Build it with Guix"-style recipes or the closer to our methods svn-fetch and git-fetch. Were it not for the fact that it uses procedures defined in (guix packages), you might have a better time reasoning that this should be a hidden part of (guix gexp), but since it does, it would introduce a cycle if you did. While (gnu packages) does offer "tools to deal with packages" as you put it, I'd argue the way it does is in establishing a namespace for them (fold-packages etc.) and that this namespace (the "GNU namespace") is the best location for computed-origin-method. The reason we use computed-origin-method at all, is because as GNU Guix we take a hard stance on the FSDG and do our damndest not to lead users to nonfree software. This includes producing clean --source tarballs. Were it not for that, we could easily deblob at build time, and this is an important observation to make, because it means that projects that don't need this level of control can "safely" defer it the way we do currently for "unpack more after unpack".[2] In other words, I strongly believe that users of compute-origin-method do the hard work of computing origins to follow GNU standards and will thereby have no issue referencing the GNU namespace to get to it. > As I said, generating this sources.json file by the website is > clunky. > Somehow, it is a quick hack to have something up waiting The Right > Way; the long-term generations should be done through the Data > Service, as it had been already discussed but not yet implemented. > Help welcome. :-) I have no opinion on that as I don't work on the Data Service. > > > About update guix package [2/2], it has to be done, IIUC. The > > > file > > > sources.json contains what the package guix provides, not what > > > the > > > current Guix has. The website -- built using the Guile tool > > > haunt -- > > > uses Guix as a Guile library. Maybe I miss something. > > > > What I was trying to say was that you wouldn't need to rebuild the > > guix package before applying the 50515 changes, which this one > > seems to require. Again, I'm not 100% sure that's the case, but > > IIUC (gnu packages) is its own realm in this regard. > > Hum, maybe there is a misunderstanding here. On one hand 50620 > applies to the guix.git repo and on the other hand 50515 applies to > guix-artwork.git repo. Oh, I somehow missed that completely. Oops. > To have the sources of linux-libre and icecat reported in > sources.json and thus to get a chance to have them archived by SWH, > we need: > > a- if computed-origin-method is factorized then update the guix > package (Guix as a library) else do nothing; patch applied to > guix.git > b- tweak how sources.json is built; patch applied to guix- > artwork.git > > Well, the aim of 50620 is to deal with a) whereas the aim of 50515 is > to deal with b). Note that 50515 requires a v2 if > computed-origin-method is factorized. > > Maybe I miss something. From my understanding, all the modules are > part of Guix as a library. Therefore, it does not depends on where > we refactorize. No, no, I was wrongly under the impression that this sources.json would be generated by Guix itself what with all the other SWH interaction we already have. Again, a mistake on my part. > To be honest, I thought that this tiny improvement of the SWH > coverage would have been much more easier and that that trivial task > would not have taken more than 15 days with lengthy discussions. :-) To be honest, part of the lengthy discussion was me being confused about your intent – in multiple ways. If you wanted a "quick and dirty fix" you could have went with checking those two modules explicitly on the guix-artwork side and it would have had a fairly small impact. Reading this patch first and the discussion second, I had assumed your intent was rather to formalize a method that had hitherto only been used informally and the move to the guix namespace amplifies that imo. All the best, Liliana [1] The only solution is of course to compare via equal? instead of eq?, which if implemented for functions would be Turing-hard :) [2] Of course, this assumes that other projects don't want to actually unpack dependencies when using --source, but I think it's likelier they will just use recursive submodule checkout. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 16:21:14 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 20:21:14 +0000 Received: from localhost ([127.0.0.1]:50365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVg4n-0005yS-Ts for submit@debbugs.gnu.org; Wed, 29 Sep 2021 16:21:14 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:38819) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVg4m-0005yF-69 for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 16:21:12 -0400 Received: by mail-wr1-f43.google.com with SMTP id u18so6269971wrg.5 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 13:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=Jvi8XyeBw1FFkjych6VDEpkIl9nOfr9upigC0fRps9g=; b=SU904B8ewPlfxp7nwzw7FC1Ew/FvE7pRTY7Jxue+sqpi62+QLRusAcPIO7yxLDcC0r I7nYZWFgyhl7aafTj+uIMxRAODDi3TrlGIDS6YRbESRPmiemO0qaNekHntD5YkRr0p86 GafkAcrnSGlkvgcOKXXyJh4RBScR1i3rUCLIgdHgSTA5ZSa5QLZYcstKmObbcTvt6GGc sTCqcWgHYv4pfRPk/Y8Z5rzZeM2PU6jbqPYk5ioLJBCEt7MhnitS9y/3/obhqbqFena1 1TKlkgHL3EWkbLrlVdHo4BdO0jUgsWOhJzHkUuDVaKoRhKl/LKR04L/y6cxP000UMGc1 Kqhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=Jvi8XyeBw1FFkjych6VDEpkIl9nOfr9upigC0fRps9g=; b=qIQEJAXmMuYgZmEZ2H2U/pRsalAW/fCia6/6QABKYk/KmsKKaCcGNLaXUWMW3opT9T 62UtbbarwXgo2qe5wO15bestslv8TfXFceT4n2kf4wplf/5bkaDsnZKZksy1f2flVox+ 0D9SDg09MjvGb6k4FZOOygfE0aTxhpvxPdWdYjLc6UAFZLcY4DaXe7jwvBCrc4upaYUG op3SQ2OQgGb5XfFYfShIfn+fSWf7G+pum9+MDhrYonkIUCZ6u9RreQXddmspPYVFMA06 1IbT3tNVB4UwS7u0wrEKOVOtaJ3TzYb7CBLOqintrMnf+qo4zxDyX35AZGKgXBAee76D 7WYg== X-Gm-Message-State: AOAM531v4Orn4cVZ99NUToTtUw3ve1DRMceJN+yYrKgnMZy0peqaINR5 FoC+4gKv/Ft/4RGVvH0hxOlGDk4XOur9NA== X-Google-Smtp-Source: ABdhPJznAz2kbWzsLZypdFvC2GvYdm47i9AiH3b+lA6H9RnMn3raBAa2ur3v8gmXk+hQY81vjW3F2g== X-Received: by 2002:adf:b185:: with SMTP id q5mr538919wra.359.1632946866310; Wed, 29 Sep 2021 13:21:06 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id i2sm820916wrq.78.2021.09.29.13.21.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 13:21:05 -0700 (PDT) From: zimoun To: Liliana Marie Prikler Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> Date: Wed, 29 Sep 2021 22:15:02 +0200 Message-ID: <861r57dtq1.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi Liliana, On Wed, 29 Sep 2021 at 21:10, Liliana Marie Prikler wrote: > I could > roll my own channel with the exact same computed-origin-method > copypasta'd once more and it wouldn't be detected, though that's > probably off-topic.[1] If it is in your own channel, then it will not be part of the file https://guix.gnu.org/sources.json. >From my understanding, you are arguing about corner cases that does not happen now. And if it happens in the near future, we will fix it, depending on what will really happen in this very future. ;-) > I was a little confused when I read factorize from Ludo or refactorize > from you. I know this technique under the name "refactoring". Indeed. Maybe a false-friend from French. :-) >> *refactorize: I think (guix packages) is better because it defines [...] >> half-mentioned this rationale. > > To that I would counter, that (guix packages) only defines package and [...] > issue referencing the GNU namespace to get to it. I hear your argument. Well, I will not discuss it. Raise as an answer to Ludo, maybe. >> To be honest, I thought that this tiny improvement of the SWH >> coverage would have been much more easier and that that trivial task >> would not have taken more than 15 days with lengthy discussions. :-) > > To be honest, part of the lengthy discussion was me being confused > about your intent =E2=80=93 in multiple ways. If you wanted a "quick and= dirty > fix" you could have went with checking those two modules explicitly on > the guix-artwork side and it would have had a fairly small impact. > Reading this patch first and the discussion second, I had assumed your > intent was rather to formalize a method that had hitherto only been > used informally and the move to the guix namespace amplifies that imo. The cover letter [1] says: =C2=ABThis patch follows the discussion from [0]= .=C2=BB where [0] points to the Mark=E2=80=99s approval as an answer to a patch whi= ch applies to website/apps/packages/builder.scm. Then the cover letter [1] says: =C2=ABIn short, it simplifies the code generating the file 'sources.json' used by Software Heritage to ingest all the tarballs.=C2=BB 1: I am sorry if this cover letter was not enough explicit about my intent. >From my point of view, the aim of this cover letter was to invite to read first the discussion and second read the patch. My bad if this aim had been missed. I apologize for the confusion. Being optimistic, this discussion leads to some concerns about this =E2=80=99computed-origin-method=E2=80=99 and ideas for improving. IMHO, it= is worth to open another issue providing the wish of multi-origin packages and reference to this. WDYT? All the best, simon From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 16:44:22 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 20:44:22 +0000 Received: from localhost ([127.0.0.1]:50397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVgRB-0006Yd-W5 for submit@debbugs.gnu.org; Wed, 29 Sep 2021 16:44:22 -0400 Received: from world.peace.net ([64.112.178.59]:53238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVgR8-0006YO-Sb for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 16:44:19 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVgQm-000635-Uu; Wed, 29 Sep 2021 16:43:57 -0400 From: Mark H Weaver To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) In-Reply-To: <87a6jv8qu7.fsf_-_@gnu.org> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <87a6jv8qu7.fsf_-_@gnu.org> Date: Wed, 29 Sep 2021 16:42:21 -0400 Message-ID: <87h7e3glkn.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Liliana Marie Prikler , 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: -1.0 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > A better solution IMO would be to improve the =E2=80=98snippet=E2=80=99 m= echanism in the > first place. =E2=80=98computed-origin-method=E2=80=99 improves on it in = two ways: (1) > lazy evaluation of the gexp, and (2) allows the use of a different base > name. > > I would think #2 is addressed by the =E2=80=98file-name=E2=80=99 field (i= sn=E2=80=99t it?). Using the 'file-name' field would not satisfy my requirements. It has two problems: (1) It would cause the unmodified upstream Firefox source tarball to be named "icecat-=E2=80=A6" in the store. (2) Although the resulting tarball would be named "icecat-=E2=80=A6", the toplevel directory name within that tarball would still be named "firefox-=E2=80=A6". I consider each of these flaws to be unacceptable. What do you think? Thanks, Mark --=20 Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about . From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 17:34:25 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 21:34:25 +0000 Received: from localhost ([127.0.0.1]:50509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhDd-0007s1-Eo for submit@debbugs.gnu.org; Wed, 29 Sep 2021 17:34:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhDc-0007ro-FO for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 17:34:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46788) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVhDW-00051n-Hk; Wed, 29 Sep 2021 17:34:18 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=36426 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVhDW-0002cR-9E; Wed, 29 Sep 2021 17:34:18 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Mark H Weaver 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> <87h7e3glkn.fsf@netris.org> Date: Wed, 29 Sep 2021 23:34:16 +0200 In-Reply-To: <87h7e3glkn.fsf@netris.org> (Mark H. Weaver's message of "Wed, 29 Sep 2021 16:42:21 -0400") Message-ID: <875yuj6p7r.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: Liliana Marie Prikler , 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 Mark, Mark H Weaver skribis: > Ludovic Court=C3=A8s writes: > >> A better solution IMO would be to improve the =E2=80=98snippet=E2=80=99 = mechanism in the >> first place. =E2=80=98computed-origin-method=E2=80=99 improves on it in= two ways: (1) >> lazy evaluation of the gexp, and (2) allows the use of a different base >> name. >> >> I would think #2 is addressed by the =E2=80=98file-name=E2=80=99 field (= isn=E2=80=99t it?). > > Using the 'file-name' field would not satisfy my requirements. It has > two problems: > > (1) It would cause the unmodified upstream Firefox source tarball to be > named "icecat-=E2=80=A6" in the store. > > (2) Although the resulting tarball would be named "icecat-=E2=80=A6", the > toplevel directory name within that tarball would still be named > "firefox-=E2=80=A6". > > I consider each of these flaws to be unacceptable. Oh I see. I agree it=E2=80=99d be nice to have a way to fix those. Perhaps by allowing for custom pack-and-repack procedures? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 17:42:39 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 21:42:39 +0000 Received: from localhost ([127.0.0.1]:50513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhLb-00083T-BC for submit@debbugs.gnu.org; Wed, 29 Sep 2021 17:42:39 -0400 Received: from world.peace.net ([64.112.178.59]:53308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhLY-00083G-OM for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 17:42:37 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVhLC-0001hi-CM; Wed, 29 Sep 2021 17:42:14 -0400 From: Mark H Weaver To: zimoun , Liliana Marie Prikler Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> Date: Wed, 29 Sep 2021 17:40:39 -0400 Message-ID: <87ee97givh.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 50620@debbugs.gnu.org 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: -1.0 (-) Hi Simon, zimoun writes: > On Wed, 29 Sept 2021 at 16:36, Liliana Marie Prikler > wrote: > >> > Perhaps I am wrong about option (2) -- my claim is that >> > computed-origin-method is *always* used with a promise so it is for >> > sure an half-baked guess but enough; and it avoids to hard code the >> > modules from where the packages come from. Therefore, option (2) >> > does not improve, IMHO. >> >> The probability of having a promise when using computed-origin-method >> is 100%. What is the probability of having computed-origin-method when >> you see a promise? The answer is: we don't know. We can see from the > > You mean, what is the probability of having a computed-origin-method > when the origin-uri is a promise? We do not know, but pragmatically, > for now 100%. :-) To my mind, that's not good enough. I consider it unsafe, and poor programming practice, to force a promise without first knowing what that promise represents and what are the implications of forcing it. In projects as large as Guix, if it becomes accepted practice to introduce lots of assumptions scattered around the code that are "for now 100%" true, the result is eventually a very brittle project where it's difficult to make changes without random stuff breaking. > Option (2) is: > > ___ (or (eq? method (@@ (gnu packages gnuzilla) computed-origin-method)) > _______ (eq? method (@@ (gnu packages linux) computed-origin-method))) > > then I ask you similarly: what is the probability of having packages > using computed-origin-method in these 2 modules only? We do not know, > but pragmatically, for now 100%. :-) The potential failure mode here is far less bad. In this case, if someone else makes another clone of 'computed-origin-method' in another module and forgets to update this code, the worst case is that some source code fails to be added to SWH. Incidentally, I guess that's the same outcome that would happen if someone adds a brand new 'origin-method' and forgets to update this code. Incidentally, I have a suggestion for how to avoid that failure mode properly, once and for all: issue a warning if we're unable to identify the 'method' of the origin at hand, calling attention to the fact that there's an unhandled case in this code. This is precisely analogous to Standard ML's *very* useful feature of issuing warnings at compile time in case of an non-exhaustive 'match' form. What do you think? In any case, thanks very much for your efforts to push this issue toward resolution. Regards, Mark -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about . From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 17:47:50 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 21:47:50 +0000 Received: from localhost ([127.0.0.1]:50517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhQc-0008D0-0s for submit@debbugs.gnu.org; Wed, 29 Sep 2021 17:47:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhQa-0008Cm-9B for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 17:47:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47462) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVhQU-0007ti-SV; Wed, 29 Sep 2021 17:47:42 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=36428 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVhQU-0006l0-FC; Wed, 29 Sep 2021 17:47:42 -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> Date: Wed, 29 Sep 2021 23:47:40 +0200 In-Reply-To: (Liliana Marie Prikler's message of "Wed, 29 Sep 2021 17:34:27 +0200") Message-ID: <87pmsr5a0z.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, Liliana Marie Prikler skribis: > Am Mittwoch, den 29.09.2021, 15:16 +0200 schrieb Ludovic Court=C3=A8s: >> Hi there! >>=20 >> I=E2=80=99d rather go with zimoun=E2=80=99s original patch, which is foc= used and does >> nothing more than what was originally intended, which is to factorize >> the procedure. I=E2=80=99ll go ahead and apply it shortly if there are = no >> objections. > I have trouble understanding this paragraph. What exactly is "this > patch" and what do you mean by "factorizing"? If it means moving > computed-origin-method elsewhere, then yes, for a short-time solution > only moving it is a wise choice in my opinion, OK, I agree too. > but zimoun and I still disagree on the target. zimoun says (guix > packages) for reasons unknown to me, whereas I say (gnu packages), > because it's closer to where it's used and doesn't imply that this is > going to be a part of the (guix) download schemes anytime soon. (gnu packages) is higher-level: it=E2=80=99s part of the distro and include= s CLI helpers such as =E2=80=98specification->package=E2=80=99. So I think (guix= =E2=80=A6) is somewhat more appropriate. (That said, what matters more to me is how we=E2=80=99re going to replace it with a proper solution.) [...] >> A better solution IMO would be to improve the =E2=80=98snippet=E2=80=99 = mechanism in >> the first place. =E2=80=98computed-origin-method=E2=80=99 improves on i= t in two >> ways: (1) lazy evaluation of the gexp, and (2) allows the use of a >> different base name. >>=20 >> I would think #2 is addressed by the =E2=80=98file-name=E2=80=99 field (= isn=E2=80=99t it?). >>=20 >> As for #1, it can be addressed by making the =E2=80=98snippet=E2=80=99 f= ield delayed >> or thunked. It=E2=80=99s a one line change; the only thing we need is to >> measure, or attempt to measure, the impact it has on module load >> time. >>=20 >> Thoughts? > This would work for packages, whose source are some base source with > patches or snippets applied, as is indeed the case for linux and > icecat. However, there are also other potential uses for computed > origins. It=E2=80=99s hard for me to talk about potential uses in the abstract. :-) There might be cases where an origin simply isn=E2=80=99t the right tool an= d one would prefer =E2=80=98computed-file=E2=80=99 or something else. It really = depends on the context. [...] > I think that some version of `computed-origin-method' will eventually > need to become public API as such packages may not always be best > described as "a base package with a snippet". If we had recursive > origins =E2=80=93 i.e. origins, that can take origins as inputs =E2=80=93= we might be > able to do some of that, but I don't think it would necessarily work > for linux-libre or icecat, as with those you don't want the tainted > versions to be kept around. Perhaps this could be worked around by not > interning the intermediate origins, but only using their file-names > inside the temporary directory in which the snippet is applied? =E2=80=9CRecursive origins=E2=80=9D are a bit of a stretch as a concept IMO= ; what you describe is a case where I=E2=80=99d probably use =E2=80=98computed-file=E2= =80=99 instead. > Another thing is that the final act of the linux-libre promise is not > the packing of the tarball, but the deblob-check. Guix currently lacks > a way of modeling such checks in their origin, but I'd argue it would > need one if we wanted to do computed origins via snippets. This is not > required by icecat and so one "simplification" could be that computed- > origin-method would not require the user to create a tarball, but > instead simply provide a name for the tarball and a directory to create > it from (via a promise again). Ah, I had overlooked that =E2=80=98deblob-check=E2=80=99 bit. It could be = that allowing for custom pack-and-repack procedures would be enough to address it. > 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? 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, that= =E2=80=99s how came to be (we could have used instead with a suitable build system). There=E2=80=99s a tension between =E2=80=9Cpurely declarative=E2=80=9D and = =E2=80=9Cflexible=E2=80=9D, and it=E2=80=99s about striking a balance, subjectively. Hope that makes sense! Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 18:13:59 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 22:13:59 +0000 Received: from localhost ([127.0.0.1]:50553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhpu-0000Ow-S3 for submit@debbugs.gnu.org; Wed, 29 Sep 2021 18:13:59 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:38872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVhpr-0000Og-NR for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 18:13:57 -0400 Received: by mail-wm1-f65.google.com with SMTP id 205-20020a1c01d6000000b0030cd17ffcf8so6536785wmb.3 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 15:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=vQgL8nnBg9X6KnJk0WacwZelrTG5OehIFCX+EVOUfOI=; b=mdTATOzYZt8C4yJ/nxCEuUganp7E53goG8bLdVcdZhl2DEDHzdxoYLzYmRgN9VLW1o BTDEscM2ugk/Y/+Btygow5wdY4MVoPl6yVGygE0jWl8GFW4i/jDcL319TroNmZhCwZzp 1frYnOGabbAJzZyDVvdgjZ/bDJgRMelSbGRXq9DQ0v7c5Ne61+vFGmuTT1vKHG34Idqy nf5sn+NcK10F9pc6UXKDumsLt3H3PyK7Lg5GxMeuvhGGwW6IrbPBvGsMs18LldS9G9Iy dCiv5RK5nyZXaxd33xwtpM/GQ3VHnhIA3cORCw7f+8xGuj5031SP2zJ1N4zboHDD13p5 y79Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=vQgL8nnBg9X6KnJk0WacwZelrTG5OehIFCX+EVOUfOI=; b=n/k9kqJZqfLEvhJkSn0gbSTI2z1x420/IQPlLuUNEVDdIODr+nTUjnc3dI/KP7+yiU l7PuoX2HxoEY17ozmuALNy96yCGPmfYo/ZkuNOguRFyyrDzYEcay51jhFoctisrCzl7k xdBwS03yFB05Ntu3zNShVlpAb2YrtgJAs0UZ/IHbNBEyq0rMJ6RkNP/HY3h33JYdriU4 1gN1qpEBnJ1pqQ7vfQLJ52WDmVt19gl4fGIClm+EvWq08Xrs/NX8I+rCrA1NohQYrpIQ ZkLhrXflmChb0zalZNax0gTWy3UUGfbp1R9wsqfPYPMNHB6ruqUYJ9+XL6qAmzzHShEJ 3sdA== X-Gm-Message-State: AOAM533BwOLzHj6fE1b83loWq5xpNhhn2jpAD9I2UYCrdLQh6hwY+YDb MpHmvqxuk2mkKp3Lc4k5MEI= X-Google-Smtp-Source: ABdhPJxyIAM6GyDsNe3d+juCjEafE4GFXfd2+swmP4GSD6iCtIwkTyTY4PzlRwR+H/sYN5iP7PMGlQ== X-Received: by 2002:a1c:7508:: with SMTP id o8mr12734640wmc.104.1632953629704; Wed, 29 Sep 2021 15:13:49 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id l18sm1062396wrp.56.2021.09.29.15.13.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 15:13:49 -0700 (PDT) Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun Date: Thu, 30 Sep 2021 00:13:48 +0200 In-Reply-To: <861r57dtq1.fsf@gmail.com> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> <861r57dtq1.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi zimoun, Am Mittwoch, den 29.09.2021, 22:15 +0200 schrieb zimoun: > Hi Liliana, > > On Wed, 29 Sep 2021 at 21:10, Liliana Marie Prikler < > liliana.prikler@gmail.com> wrote: > > > I could roll my own channel with the exact same computed-origin- > > method copypasta'd once more and it wouldn't be detected, though > > that's probably off-topic.[1] > > If it is in your own channel, then it will not be part of the file > https://guix.gnu.org/sources.json. > > From my understanding, you are arguing about corner cases that does > not happen now. And if it happens in the near future, we will fix > it, depending on what will really happen in this very future. ;-) The patch mentions "automatic detection of computed-origin-method" which I would assume has implication beyond this sources.json. But yeah, I can see that it's off-topic to this discussion, hence why I wrote that it's probably off-topic to this dicussion. > > > *refactorize: I think (guix packages) is better because it > > > defines > > [...] > > > > half-mentioned this rationale. > > > > To that I would counter, that (guix packages) only defines package > > and > > [...] > > > issue referencing the GNU namespace to get to it. > > I hear your argument. Well, I will not discuss it. Raise as an > answer to Ludo, maybe. I did already mention that in my reply to Ludo, so we'll see. > > > To be honest, I thought that this tiny improvement of the SWH > > > coverage would have been much more easier and that that trivial > > > task > > > would not have taken more than 15 days with lengthy discussions. > > > :-) > > > > To be honest, part of the lengthy discussion was me being confused > > about your intent – in multiple ways. If you wanted a "quick and > > dirty fix" you could have went with checking those two modules > > explicitly on the guix-artwork side and it would have had a fairly > > small impact. > > Reading this patch first and the discussion second, I had assumed > > your intent was rather to formalize a method that had hitherto only > > been used informally and the move to the guix namespace amplifies > > that imo. > > The cover letter [1] says: «This patch follows the discussion from > [0].» where [0] points to the Mark’s approval as an answer to a patch > which applies to website/apps/packages/builder.scm. > > Then the cover letter [1] says: «In short, it simplifies the code > generating the file 'sources.json' used by Software Heritage to > ingest all the tarballs.» > > 1: > > I am sorry if this cover letter was not enough explicit about my > intent. From my point of view, the aim of this cover letter was to > invite to read first the discussion and second read the patch. My > bad if this aim had been missed. I apologize for the confusion. Again, I read the patch itself first and the context second, but speaking about "simplifying the code generating sources.json", the real change were we to compare (2) and (3) or (3a) to each other would be a 3 line diff (two deletions, one insertion). So I do think it is fair to also talk about implications beyond those three lines. Also, even with this context in mind, the patch at first appeared to me as a way of sneaking (1) past the radar, rather than the three-line diff that one would see when looking at it from 50515 with (2) applied. > Being optimistic, this discussion leads to some concerns about this > ’computed-origin-method’ and ideas for improving. IMHO, it is worth > to open another issue providing the wish of multi-origin packages and > reference to this. WDYT? Since it's but an idea sketch in my head at the moment, I think the best we could muster discussing this outside of this thread would be on guix-devel. Which is fine and all, but since we're looking in this thread for something comparatively small in scale I'd say let's look at the small issue first and the big issue once we've fixed the small one. Let's shortly recap what options we have. A: Push a v2 of 50515 guix-artwork, which references (gnu packages linux) and (gnu packages gnuzilla) using @@. Then decide on which module we want to have computed-origin-method to be in and update the guix package. Finally, update the sources.json generator to use the singular reference. B: Push the lazy v2 as above, but instead hold up the cleaning up part until we find a solution for the computed-origin-method in this thread or guix-devel. C: Discuss the (gnu packages) vs. (guix packages) thing some more, merge this patch (with perhaps a move), update the guix package and then do a v2 of 50515. C2: Have Ludo flip a coin and decide. D: Have computed-origin-method block the sources.json generator until it is completely resolved. We obviously want to avoid D here and are somewhat aiming for C at the moment instead. However, we are kinda stuck here as even though we don't want this situation to continue indefinitely, we can't seem to reach a consensus quickly. WDYT? Does it make sense to do the "redundant test" [1], knowing that it'll be soon simplified? Can we hold off more computed-origin-method clones until we find a way of making do without it or actually decide that it's public API? All the best, Liliana [1] From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 18:46:24 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 22:46:24 +0000 Received: from localhost ([127.0.0.1]:50772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mViLI-0001OJ-Br for submit@debbugs.gnu.org; Wed, 29 Sep 2021 18:46:24 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:45902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mViLF-0001O2-PC for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 18:46:22 -0400 Received: by mail-wm1-f49.google.com with SMTP id b192-20020a1c1bc9000000b0030cfaf18864so2834830wmb.4 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 15:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=ggpZsnItJhtzi0N5WU94R8sgVRNfZh8h86e+N5XtFEc=; b=dh8YPkeX7uIYYYFqfdo9NDLjsz5jPH1uyaa342iBqHmVJhtse5dtJaytkfxfb6Iu6t LeL+6b7d/eK7rjQvmi0IUjXJoZoBkpJ89K/c9EFpG/9lG6ZhV6rC0eKyUoEKYLj/g8O+ bWBgHhK+v6Wgna3JSG3ufhw89ojlN0KxQu5nhChZ0+tGisL7+TmAkqP9xTJ5dQSIp8I1 sA4f178PoAv7giP5uJUKDE7AmyKi6fKKOw23/rUFrXtW138fZ/PYnB41/xH7IkyWA+7a 7NsoSdrxuaUxuhK/wmgD4FehrdGGE7eOSph7V4L9KhX327tuaYOSgoelQmCq81E21wIJ flYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=ggpZsnItJhtzi0N5WU94R8sgVRNfZh8h86e+N5XtFEc=; b=exqN87VNUq0W+DJqaQaBv6SIiu+/K6AfXCdG7/KJ3mwPIruBU+KiW3ZEhLt8WfPu4u GIPdBOaK1kuKKRbdjy3zsTf+DtEQwl51jaCvaMgeYwo92eu05QKJTU1vmnIEVzzS+Hk8 xPiESE/RdQoeK7hmbsVakc71/j98OFAVeu3LvSTl6n45LhN7xgV8T0Bp1znB7JN4xkLJ O8GNetVXXH0DASGuz5hI3KZ7NMlFnf9PS/Z9w0Nz42nkhDQ1RB0InP96FImbqNFuenDj 7M67VUfc5GOYq20uURR99jBbQdAFAU4WNPhm0K6J2COt7//2WJAhAk9wTkR50EfrHxrX sA6g== X-Gm-Message-State: AOAM533MT6vjy0y9Lfch8nA8MtJXG54KRltKGG0eeTqAfJP8i8ha6iCb wUzKotCurO7NiJ4aB0TdmiSUTZsIZb3Ikw== X-Google-Smtp-Source: ABdhPJxawga7FvKFaWX9vZB9REp1mErKjWIFcsebBdL6yU9RZFDgcQGbZad9WA6Hf6JYfYHiqOyvow== X-Received: by 2002:a05:600c:1c9a:: with SMTP id k26mr2281104wms.169.1632955575658; Wed, 29 Sep 2021 15:46:15 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id e8sm1096466wrr.42.2021.09.29.15.46.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 15:46:15 -0700 (PDT) From: zimoun To: Mark H Weaver , Liliana Marie Prikler Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. In-Reply-To: <87ee97givh.fsf@netris.org> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> <87ee97givh.fsf@netris.org> Date: Thu, 30 Sep 2021 00:45:58 +0200 Message-ID: <86v92jc861.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 50620@debbugs.gnu.org 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: -1.0 (-) Hi Mark, On Wed, 29 Sep 2021 at 17:40, Mark H Weaver wrote: > zimoun writes: > To my mind, that's not good enough. I consider it unsafe, and poor > programming practice, to force a promise without first knowing what that > promise represents and what are the implications of forcing it. > > In projects as large as Guix, if it becomes accepted practice to > introduce lots of assumptions scattered around the code that are > "for now 100%" true, the result is eventually a very brittle project > where it's difficult to make changes without random stuff breaking. I agree=E2=80=A6 >> Option (2) is: >> >> ___ (or (eq? method (@@ (gnu packages gnuzilla) computed-origin-method)) >> _______ (eq? method (@@ (gnu packages linux) computed-origin-method))) >> >> then I ask you similarly: what is the probability of having packages >> using computed-origin-method in these 2 modules only? We do not know, >> but pragmatically, for now 100%. :-) > > The potential failure mode here is far less bad. In this case, if > someone else makes another clone of 'computed-origin-method' in another > module and forgets to update this code, the worst case is that some > source code fails to be added to SWH. Incidentally, I guess that's the > same outcome that would happen if someone adds a brand new > 'origin-method' and forgets to update this code. =E2=80=A6and I also agree. That=E2=80=99s why, right after this quotation,= I wrote: That's why the option (3): (eq? method (@@ (guix packages) computed-origin-method)) which means refactorize*. It is somehow the two worlds: check i.e., safer, no modules hard-coded and keep private the time to have The Right Plan for this computed-origin-method. which is *exactly* what you are asking, IIUC. To be honest, I do not understand why we are discussing at length this trivial path: for guix.git: 1. move the duplicate computed-origin-method to a single place 2. keep it private 3. add comments about that for guix-artwork.git: 4. guard the promise using a check against: (@@ (module somewhere) computed-origin-method) for guix.git 5. update the package guix done! :-) It changes nothing on the Guix side. Do we not agree on this trivial path? Re-reading from the starting point 50515 and then 50620, the trivial road appears to me clear. I apologize if it was not or to not make it explicit earlier. >From my understanding, we all agree, somehow; because it fixes the current situation and let the time to cook The Right Plan for this computed-origin-method. Where we can discuss is #2 but as it is already mentioned, it is out of scope for sources.json, IMHO. If I knew all what would happen, then I would send a v2 for 50515 using what you described as option (2). :-) My aim with this 50620 was just to simplify at very low cost the code (belonging to the repo guix-artwork.git) which generates . The v2 (adding a guard) for 50515 is simply waiting the output of this 50620; because this guard depends if computed-origin-method is defined at an unique location or at two different locations. =20=20 > Incidentally, I have a suggestion for how to avoid that failure mode > properly, once and for all: issue a warning if we're unable to identify > the 'method' of the origin at hand, calling attention to the fact that > there's an unhandled case in this code. This is precisely analogous to > Standard ML's *very* useful feature of issuing warnings at compile time > in case of an non-exhaustive 'match' form. The SWH reader which consumes this sources.json file does not care about a warning. And AFAIK no one is reviewing by hand this sources.json file. Specifically, the only purpose of this very file is to be consumed by the SWH infrastructure. It is automatically generated when the Guix website rebuilds; the content of this file depends on the version of the package guix. That=E2=80=99s said, there is room of improvement to track what is the arch= ival coverage by SWH. Today, we do not have a clear picture of the packages archived by SWH. By archived, it means packages for which Guix is able to fallback and lookup using the SWH archive. Well, now one foot, now the other. :-) (On a side note, I agree that this ML feature is very useful. From my understanding, it requires a kind of type system that Guile does not have. Sadly.) > In any case, thanks very much for your efforts to push this issue toward > resolution. Thanks. At one point, I felt demotivated then reconsidering the energy we all are putting it, we have to resolve. :-) All the best, simon From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 19:41:25 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 23:41:25 +0000 Received: from localhost ([127.0.0.1]:50970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVjCX-0002us-9g for submit@debbugs.gnu.org; Wed, 29 Sep 2021 19:41:25 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:34438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVjCT-0002ub-Go for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 19:41:24 -0400 Received: by mail-wr1-f50.google.com with SMTP id t8so6973561wri.1 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 16:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references :disposition-notification-to:date:message-id:mime-version :content-transfer-encoding; bh=vV9P9xpSShjtDrMgiMj+Y4TBr3sVv/HJ52lYbNRL3E4=; b=UQGN7LSjOHL6NjZXe3YatMTWd/29lfljLBT6w0XoAkhueVvbeWjFz+yhwZKDgIQziF 2QBDOtHqaETYdrIZQ/mlvCSRxtxIZKCCkbAMQRaSZpR6N/gwL4OtEv0vdLXgE6Tp31Yw p82DjanFWW7UiVcSzbjlZuelLfZQQEMKgfk5vy1vWW4vgEeZ6XqhugWSbGSck6IcC8Um dggXAj5ZDb+Z+o7vhxloJY2OFCpOMYPNM9niBkCDPMqpvqDwOrNz0cJN2MjDBMfPcaWB 5icrHwMw8ZYJTgv/OpdqcQEfMsodcNEE8pladkVyIqkNv+45f9zLA0wir29QfLJoda3N 0jnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :disposition-notification-to:date:message-id:mime-version :content-transfer-encoding; bh=vV9P9xpSShjtDrMgiMj+Y4TBr3sVv/HJ52lYbNRL3E4=; b=RLhyZmwIqzLqhD7PRj1TrYtG8g1Kx1tw2jfEB+rWjLvnCl3HS1DAZ4rqUxoIXGk6Mg E/hzoFBiBvHWPm1kd8jCRYvj59RkmaxV0wvp26Hosl7zkvU2kMDkf9UGnoYpyIxAN+hz 4r/nqSp4q0JHLhwKlx7tfenZ9cOZxVcp5o6TdYiZc4CfBT/kzh9nLHVuJcphvbFXcdoU 9/lV8PBPjHpVOrBlvcJ4g3uWgLDnVDNFeNmxNQTmi9QFQ8Nsv0Wx1ZYk6pqi5TvMOD+9 d/gdWDPs+gDPgOI6kb+VAVG1C3/1ycaJlFnGuRrEHYDBUPFBq1sAJaQepnnkvWrvVSy/ hA4Q== X-Gm-Message-State: AOAM533BQqBDPr6BUYIJeybbh4aL7Vt+n3gqyPq1oZnipiGOTZAnXTmD VVtpRABOx99GRhecbLt1G8EI9kqp+G2ZBQ== X-Google-Smtp-Source: ABdhPJw8pLDIIaWjgx5+tn82LIX6kPD0B6fF1D6ojmYbsjepkUqVvvoBgqJ1Neau61r3KX+BdqpG/w== X-Received: by 2002:a05:6000:12d0:: with SMTP id l16mr2899124wrx.139.1632958875465; Wed, 29 Sep 2021 16:41:15 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id 20sm3149937wme.46.2021.09.29.16.41.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 16:41:14 -0700 (PDT) From: zimoun To: Liliana Marie Prikler Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> <861r57dtq1.fsf@gmail.com> Date: Thu, 30 Sep 2021 01:31:04 +0200 Message-ID: <86o88bc62v.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org 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: -1.0 (-) Hi, On Thu, 30 Sep 2021 at 00:13, Liliana Marie Prikler wrote: > C: Discuss the (gnu packages) vs. (guix packages) thing some more, > merge this patch (with perhaps a move), update the guix package and > then do a v2 of 50515. This is the option I am for. Even, the patch is ready and waiting since =C2=ABFri, 10 Sep 2021 18:01:22 +0200=C2=BB. ;-) The patch reads: --8<---------------cut here---------------start------------->8--- + (if (eq? method (@@ (guix packages) computed-origin-method)) + ;; Packages in gnu/packages/gnuzilla.scm and gnu/packages/linux.scm + ;; represent their 'uri' as 'promise'. + (match uri + ((? promise? promise) [...] + (_ `((type . #nil)))))) + ;;Regular packages represent 'uri' as string. + `((type . ,(cond ((or (eq? url-fetch method) --8<---------------cut here---------------end--------------->8--- and I find better (guix packages) but I do not have a strong opinion; I accepted previously in this thread to send a v2 with (gnu packages) or whatever other location. > WDYT? Does it make sense to do the "redundant test" [1], knowing that > it'll be soon simplified? I do not mind about option (2) which reads: --8<---------------cut here---------------start------------->8--- + (if (or (eq? method (@@ (gnu packages linux) computed-origin-method)) + (eq? method (@@ (gnu packages gnuzilla) computed-origin-method))) + (match uri + ((? promise? promise) [...] + (_ `((type . #nil)))))) + ;;Regular packages represent 'uri' as string. + `((type . ,(cond ((or (eq? url-fetch method) --8<---------------cut here---------------end--------------->8--- Whatever. However, since it is me who takes care about how this sources.json is generated, I find easier to have one location and forget about this case. The only thing I am asking here with this patch 50620 is to locate computed-origin-method to one unique place. If people strongly disagree, then let do this option (2) and move on. Last, I am confused why all this is so complicated when it is trivial and for something outside Guix proper. I do not understand what we are discussing when my request is trivial, IMHO. This discussion has eaten all my energy allowed for Guix. See you next week. All the best, simon From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 19:44:48 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 23:44:48 +0000 Received: from localhost ([127.0.0.1]:50974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVjFn-00030d-Py for submit@debbugs.gnu.org; Wed, 29 Sep 2021 19:44:48 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:55935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVjFk-00030O-Mm for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 19:44:46 -0400 Received: by mail-wm1-f65.google.com with SMTP id v127so3108751wme.5 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 16:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=p+WnMKZprEEhpm/yNCatzO1NHCnMqxtScv2TIbL5Atg=; b=UJvy4NcEImgPGVQuvrBi4851qpEl3FAOCDq7c7rwqfIyoYcuel79pMvTW80jIgVqch Guw4aBvwNITFmZJpIlcqAtwJNHK1wOBVpT2Y5dlkuG11mKwn2w5Dfl6eHJ7IWtSd/wYu Uh61S3JGCqc8QdLApsBPhJa+4h6G1xkLFeb3v8Y4r13XNgwCN2Q0Z4S0s80ITOlJgOCL QLAfCPfPV9dnry56+s94WLPzuQxBuLmbQqSlqBOmv52hjDJwuP6CD0H73oH0dzDRMcQD VCcf6b19ldeG/EO/id3A5bEueqENqdovMghoV4ZB1mDLVfLGIGUR6G8+gwzXiHbqH4xr KCjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=p+WnMKZprEEhpm/yNCatzO1NHCnMqxtScv2TIbL5Atg=; b=P3ZK5Z159e+nMs32104EUXTYBV5oUGcrDxIo77NDDhkq7yhHJwtfdO4VqtLoIgaX11 3IrIAISzUJiUex0gBWwKXgxH1CKBTCw7PVaNS38tiLfhhQOUP3TmU/r/Yr0o0W49+Wij DbhVU20A0XPQ6JtsH129qHOpYOp90qvf0UmyRS5rNE1sJCFwfZC0Qhh2GGWSI6GNEnQN rYhponjMh+2iCBsr3FRCC2BwLEzdH8kalEa5ojVzlM2XdFjb2TCsDCNunOZHJQ44H3eO tMmFTdehuibhhh/PYLYO/obyFSlZ5mppJOnZJ49Z+wuPbO+JpHT2C0ep0Pi3EwvhbDky NJyQ== X-Gm-Message-State: AOAM531LDu4hzW/FBZJEamaNi/2KhCIi8jmqHBk7cf8UqnvUR3/BUORI 1aFoIPQT37/2ebshBOREEX4= X-Google-Smtp-Source: ABdhPJwLeco4aUNb9Kno78LT9Zs4HbAbh+V4ngvmdGiPSDz3RWziO8xoEwX0yPK2sbIkb4qIm4/Z6A== X-Received: by 2002:a7b:ce0e:: with SMTP id m14mr2435878wmc.109.1632959078789; Wed, 29 Sep 2021 16:44:38 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id l6sm1186168wrm.64.2021.09.29.16.44.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 16:44:38 -0700 (PDT) Message-ID: <09c009ec61b8f9c1746f98916f492b8953b16dcc.camel@gmail.com> Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) From: Liliana Marie Prikler To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Thu, 30 Sep 2021 01:44:37 +0200 In-Reply-To: <87pmsr5a0z.fsf_-_@gnu.org> 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) 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: -1.0 (-) Hi Ludo, Am Mittwoch, den 29.09.2021, 23:47 +0200 schrieb Ludovic Courtès: > [...] > > > but zimoun and I still disagree on the target. zimoun says (guix > > packages) for reasons unknown to me, whereas I say (gnu packages), > > because it's closer to where it's used and doesn't imply that this > > is > > going to be a part of the (guix) download schemes anytime soon. > > (gnu packages) is higher-level: it’s part of the distro and includes > CLI helpers such as ‘specification->package’. So I think (guix …) is > somewhat more appropriate. > > (That said, what matters more to me is how we’re going to replace it > with a proper solution.) (gnu packages) being high-level is part of the reason I want it there. Stuff that's hidden quite deep inside (guix something) will be slower to change and replace with the proper solution. When you pull on a lever, the outside moves faster :) > > > A better solution IMO would be to improve the ‘snippet’ mechanism > > > in the first place. ‘computed-origin-method’ improves on it in > > > two ways: (1) lazy evaluation of the gexp, and (2) allows the use > > > of a different base name. > > > > > > I would think #2 is addressed by the ‘file-name’ field (isn’t > > > it?). > > > > > > As for #1, it can be addressed by making the ‘snippet’ field > > > delayed or thunked. It’s a one line change; the only thing we > > > need is to measure, or attempt to measure, the impact it has on > > > module load time. > > > > > > Thoughts? > > This would work for packages, whose source are some base source > > with patches or snippets applied, as is indeed the case for linux > > and icecat. However, there are also other potential uses for > > computed origins. > > It’s hard for me to talk about potential uses in the abstract. :-) > > There might be cases where an origin simply isn’t the right tool and > one would prefer ‘computed-file’ or something else. It really > depends on the context. > > [...] > > > I think that some version of `computed-origin-method' will > > eventually need to become public API as such packages may not > > always be best described as "a base package with a snippet". If we > > had recursive origins – i.e. origins, that can take origins as > > inputs – we might be able to do some of that, but I don't think it > > would necessarily work for linux-libre or icecat, as with those you > > don't want the tainted versions to be kept around. Perhaps this > > could be worked around by not interning the intermediate origins, > > but only using their file-names inside the temporary directory in > > which the snippet is applied? > > “Recursive origins” are a bit of a stretch as a concept IMO; what you > describe is a case where I’d probably use ‘computed-file’ instead. In other words, we could/should use computed-file for linux-libre and icecat? If we reasonably can, would it make sense to use that in lieu of computed-origin-method to actually advertise the existence of computed-file to Guix users/packagers? > > Another thing is that the final act of the linux-libre promise is > > not the packing of the tarball, but the deblob-check. Guix > > currently lacks a way of modeling such checks in their origin, but > > I'd argue it would need one if we wanted to do computed origins via > > snippets. This is not required by icecat and so one > > "simplification" could be that computed-origin-method would not > > require the user to create a tarball, but instead simply provide a > > name for the tarball and a directory to create it from (via a > > promise again). > > Ah, I had overlooked that ‘deblob-check’ bit. It could be that > allowing for custom pack-and-repack procedures would be enough to > address it. 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. 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. > > 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? > > 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 > ‘computed-file’ or to devise a new type. After all, that’s how > came to be (we could have used instead with a > suitable build system). > > There’s a tension between “purely declarative” and “flexible”, and > it’s 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 = origin, that might have caused "computed- origin-method" to exist in the first place. What do you think? Liliana From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 03:11:24 2021 Received: (at 50620) by debbugs.gnu.org; 30 Sep 2021 07:11:24 +0000 Received: from localhost ([127.0.0.1]:51302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVqE0-00028M-BJ for submit@debbugs.gnu.org; Thu, 30 Sep 2021 03:11:24 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:35759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVqDy-000289-PU for 50620@debbugs.gnu.org; Thu, 30 Sep 2021 03:11:23 -0400 Received: by mail-wm1-f67.google.com with SMTP id z184-20020a1c7ec1000000b003065f0bc631so7522837wmc.0 for <50620@debbugs.gnu.org>; Thu, 30 Sep 2021 00:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=x9om0sZOwXLFCbBC49VFlbsj+ZuPcDHU7kZ83uvlo0U=; b=HWRRJfMTaGH+4rfB0iPOZ3t7hlUZzv5LJd0nNqwAOCPAc8RyjToUgnSKsmWq7Xsg65 UOLknxyGlLhH5qFRcz48otr6Ymmk13LY/LjjJNxG7pfQZAXqRR/Eb39nSwQa6kI5lYHg LOit/Ta35wt4ox/SdtDruaKgBsjYDvrlsZSfbfqkQJzu+2EtCpQWrJtcRJqUuxE4tJct QTIxMJDkqAdePSinHNxFnddia4IsyztPYgTXwMx1WKg/ZUimhpCqu32Fs6/a9bSSP8vM Nl5aIBAkeEn/1S5YSB7VbvnnhSNVj+GV3xCK2ArxWyM3d2bQPcPsUTRB2nYeASWbqhXT v/Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=x9om0sZOwXLFCbBC49VFlbsj+ZuPcDHU7kZ83uvlo0U=; b=Pt7AWwOjaHxXF9O1MQ/mQQtD2ZIBwrbTK67Orj2s/9KAVp5nSr2kKvnPQ41ytwuZAe chV9Lh5FaNSvMIBn6LFLhkpUidpMkyskfaVZc6wn95Qt/2U/hanVbKlrVqHrbzBAZcPa agQgxobxIVjpqtNZN5Z9RgR68hFPnpOv93us7ub9oIAvGWx2qPfWkyDpfwTVJVdyoY0u KkMscwo4mq0myaJ0VfZeBg1LCSSLLyLx8kk3nV8mfjKhXwm3BMeabIVSmUTdlQqV3AYY hbkXiIUvFdGfR/uiWh3iSrLcnpNP0s3E4CMN+hDW8f2/DhUnllG1OYM1snAQoq/JzIoJ rHvg== X-Gm-Message-State: AOAM533U85JZPKMDOfZIKVX4Bnaw/UnafjqFv19xUyPYzTjrMo6J69++ Wgszf33AV4EMiObaNRaTzr0= X-Google-Smtp-Source: ABdhPJzkGlH9Oa8uQsOBgiweiVq/NyaY9BEGcBpIGcsApWDoS02sRnLwM90AmcVl1NfSKq3Pb4wsAQ== X-Received: by 2002:a7b:cc0d:: with SMTP id f13mr3629073wmh.85.1632985876830; Thu, 30 Sep 2021 00:11:16 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id c4sm2067992wrt.23.2021.09.30.00.11.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Sep 2021 00:11:16 -0700 (PDT) Message-ID: <40b6ad5258fd8a2789ed62f857a98ac474c208fb.camel@gmail.com> Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun , Mark H Weaver Date: Thu, 30 Sep 2021 09:11:15 +0200 In-Reply-To: <86v92jc861.fsf@gmail.com> References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> <87ee97givh.fsf@netris.org> <86v92jc861.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: 50620@debbugs.gnu.org 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: -1.0 (-) Hi zimoun, Am Donnerstag, den 30.09.2021, 00:45 +0200 schrieb zimoun: > To be honest, I do not understand why we are discussing at length > this trivial path: > > for guix.git: > > 1. move the duplicate computed-origin-method to a single place > 2. keep it private > 3. add comments about that > > for guix-artwork.git: > > 4. guard the promise using a check against: > (@@ (module somewhere) computed-origin-method) > > for guix.git > > 5. update the package guix > > done! :-) > > It changes nothing on the Guix side. I've started discussing this path because we are currently stuck at 1. for some time. Given that this drags on for so long and you are looking for a "quick solution" for guix-artwork.git, I called into question whether it is really necessary to modify guix.git first. This does not change nothing for the Guix side either, it changes the location of a hack most of us wish to rather avoid than to give more attention to in the code base :) Sorry for forcing you through this, I had not intended to spark this lengthy debates. 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 10:18:11 2021 Received: (at 50620) by debbugs.gnu.org; 30 Sep 2021 14:18:11 +0000 Received: from localhost ([127.0.0.1]:53595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVwt0-0001Fg-Ib for submit@debbugs.gnu.org; Thu, 30 Sep 2021 10:18:10 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:35810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVwsn-0001Ee-CT for 50620@debbugs.gnu.org; Thu, 30 Sep 2021 10:18:09 -0400 Received: by mail-wr1-f68.google.com with SMTP id i23so10384982wrb.2 for <50620@debbugs.gnu.org>; Thu, 30 Sep 2021 07:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=AnJvLUfIo6+6caT298WVANOb0YVwp2P+hrf8SQXyVxY=; b=LcQBwb/QrxYD1gMCjBxb2OYoytuEfoq1LybyuVfY8d7VF3UwuW9Qj5SE6+Y51JxokU clYr/a1GW9Pyyu5PvwqV40O3Co2ZPNrUec8c+0cdEvEgFvYP+UeJN/z7qwYLLPXtMoov 6AAct8fV5lAHTL2gNEYlL7LGBbffNuVw5DgDceid56OzUgfW53uyCH/f8524VE/a8Zdg lsf8VfRbdJ9YAqjgPz8C9hxiqhQKKYe+rgYlmx3u9mQ86QiidqKt1R6vUaYxH5IyqBfj cQqcUKglMfbb3WYcsnkqu1FOUVvyoVvz79qhZ+TtY8j+J7IfBpsyidoKu8S1mg6slTZA 6h6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=AnJvLUfIo6+6caT298WVANOb0YVwp2P+hrf8SQXyVxY=; b=Pz5cPpP40+fHJ5V4gDL0qj9fUih3kBKQeD3lk0DF5mkyW9cp7kQ6A8xpsjYcUNQ7cM 1wF0vk3f92livO2cm9E7ck9ON6NS+nw0j8Ba5CDfCx4Fa28KClrmgfKpzB2MBPOVup6u 9WVxXjmKzF3n7hjfYRbV9qy/B5so4PC6MgrCKSri4ZGIjcBVEYMvE+meLty4qG+E4SYF kPb/JHt2LVU55KUlkJkEgjr9oQP29vWdsVOAA5anGPeJQ0SgyBaS+wyVcbiZf9bDJbGm QmOPTCtXNs0DsOKtg98cBPMHZfikj9fL9ix5YU9m+61PnAkp4WdKnYc/fpiIyGzB6YnK DznA== X-Gm-Message-State: AOAM532Y1Aw4PEarC7v6MxBLhEiKv0LJCmp2ET3Y3VZYv+KQYJd6/jZY SH/eTlOA1EsclwenjSN7Iao= X-Google-Smtp-Source: ABdhPJxChBPeDJSP936JCHfqu6a+LcvW5I5TStWuaGiGbKNs4LdzwICIV/3IpCAu23/kd8saI8y6/g== X-Received: by 2002:adf:eb12:: with SMTP id s18mr6583735wrn.97.1633011471095; Thu, 30 Sep 2021 07:17:51 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id l26sm4950316wmi.25.2021.09.30.07.17.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Sep 2021 07:17:49 -0700 (PDT) Message-ID: <735304d110f5e99c66904fc7ced3465bf1815baf.camel@gmail.com> Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) From: Liliana Marie Prikler To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Thu, 30 Sep 2021 16:17:48 +0200 In-Reply-To: <87r1d64gd3.fsf_-_@gnu.org> 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> <87r1d64gd3.fsf_-_@gnu.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) 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: -1.0 (-) Hi, Am Donnerstag, den 30.09.2021, 10:28 +0200 schrieb Ludovic Courtès: > [...] > > 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’s 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.) Which is a practical issue because it'd mean that the tarball gets built as soon as the source is interpreted? > > > > 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? > > > > > > 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 > > > ‘computed-file’ or to devise a new type. After all, that’s how > > > came to be (we could have used instead with a > > > suitable build system). > > > > > > There’s a tension between “purely declarative” and “flexible”, > > > and > > > it’s 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 = origin, that might have > > caused "computed-origin-method" to exist in the first place. > > I’m not sure what you mean by “others may pass unhindered”? You mean > other VCS checkouts? I mean that we don't need to wrap local-file inside an origin for example whereas we do need to wrap e.g. svn-fetch instead of having an svn-checkout constructor at the top. It's not really that noticable normally, but weird once you start thinking a little too hard about it. > > 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 ‘computed-origin- > method’ addresses. > > What you propose (IIUC) sounds interesting: we’d provide a > data type, which would make the source URL > manifest (something that’s useful for < > https://issues.guix.gnu.org/50515>;, > for instance), but the lowering step would be entirely custom, > similar to what it already looks like: > > (define-record-type* computed-tarball make- > computed-tarball > 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-location)))) > > Is this what you had in mind? Slightly similar, but I don't think I'd want a singular source url. Instead (define-record-type* computed-tarball make-computed-tarball computed-tarball? this-computed-tarball (sources computed-tarball-sources) ; list of origins, local ; files or other things (builder computer-tarball-builder (thunked)) ; gexp (name computed-tarball-name) ; perhaps? (location computed-tarball-location (innate) (default (current-source-location)))) At the start of BUILDER, SOURCES are already unpacked to the current working directory under their stripped file names. After builder returns, we either package the contents of the current working directory up into a tarball (variant A) or we have builder return a list of files to pack up (variant B) which we then post-process maybe. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 16:09:22 2021 Received: (at 50620) by debbugs.gnu.org; 30 Sep 2021 20:09:22 +0000 Received: from localhost ([127.0.0.1]:54098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mW2Mr-0004jm-Rr for submit@debbugs.gnu.org; Thu, 30 Sep 2021 16:09:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mW2Mq-0004jY-Cq for 50620@debbugs.gnu.org; Thu, 30 Sep 2021 16:09:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58078) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mW2Ml-0001Ij-4t; Thu, 30 Sep 2021 16:09:15 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=36434 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mW2Mj-0007Oc-LP; Thu, 30 Sep 2021 16:09:15 -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> <87r1d64gd3.fsf_-_@gnu.org> <735304d110f5e99c66904fc7ced3465bf1815baf.camel@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 9 =?utf-8?Q?Vend=C3=A9miaire?= an 230 de la =?utf-8?Q?R=C3=A9volution?= 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, 30 Sep 2021 22:09:12 +0200 In-Reply-To: <735304d110f5e99c66904fc7ced3465bf1815baf.camel@gmail.com> (Liliana Marie Prikler's message of "Thu, 30 Sep 2021 16:17:48 +0200") Message-ID: <87wnmx3jx3.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 (---) Liliana Marie Prikler skribis: > Am Donnerstag, den 30.09.2021, 10:28 +0200 schrieb Ludovic Court=C3=A8s: >> [...] >> > 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. >>=20 >> 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.) > Which is a practical issue because it'd mean that the tarball gets > built as soon as the source is interpreted? It=E2=80=99s impractical because typical usage introduces top-level circular references (e.g., if you write #$gzip). > I mean that we don't need to wrap local-file inside an origin for > example whereas we do need to wrap e.g. svn-fetch instead of having an > svn-checkout constructor at the top. It's not really that noticable > normally, but weird once you start thinking a little too hard about it. Hmm yeah, I must not be thinking hard enough. :-) > Slightly similar, but I don't think I'd want a singular source url.=20 > Instead > > (define-record-type* computed-tarball=20 > make-computed-tarball > computed-tarball? > this-computed-tarball > (sources computed-tarball-sources) ; list of origins, local=20 > ; files or other things > (builder computer-tarball-builder (thunked)) ; gexp > (name computed-tarball-name) ; perhaps? > (location computed-tarball-location (innate)=20 > (default (current-source-location)))) > > At the start of BUILDER, SOURCES are already unpacked to the current > working directory under their stripped file names. After builder > returns, we either package the contents of the current working > directory up into a tarball (variant A) or we have builder return a > list of files to pack up (variant B) which we then post-process maybe. >=20=20 > WDYT? Overall LGTM! IWBN to see if there are other potential users in the tree (I can=E2=80=99t think of any), but for IceCat and Linux-libre, it cou= ld already improve the situation. Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 17:49:16 2021 Received: (at 50620) by debbugs.gnu.org; 30 Sep 2021 21:49:16 +0000 Received: from localhost ([127.0.0.1]:54247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mW3vY-0007M8-3Z for submit@debbugs.gnu.org; Thu, 30 Sep 2021 17:49:16 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:45638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mW3vS-0007Lr-55 for 50620@debbugs.gnu.org; Thu, 30 Sep 2021 17:49:14 -0400 Received: by mail-wr1-f65.google.com with SMTP id d21so12292423wra.12 for <50620@debbugs.gnu.org>; Thu, 30 Sep 2021 14:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=ynB7DOxt3f9FukQ4Qjyef3j9C2bfAAH4wd4oanSiqgM=; b=o0wdz8oa1gSs85Rmb7tZzF2aO3p+QBI7fFJvRvkrcAptAS8LhFJeRZNebMK2jek6Ic jITmo8sZC+mBD3IrW2kk4r6cpGj+a3ijZPDk1nyT52mAuAKn+7v1tDPdVFMG064d3WJZ pH6mgZ+pKjeyQvmoeAFBZVsX7ufHhgtyIfFch3ds7obApoOB4bTyJajV44WzkA85Skia S/wYLsoTOJBMxbFIJ7VbK8EAwM+Y1fyEuseeOPnwNDP3wc1g1LFV9gI8dOnHmfcKMpB2 fZ3HzjacCVsWV7z/827Q7hH62hCFGmNGNbAchfMfWD5fSe3klRUiQ57L2fAC/FBd57Dk Np4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=ynB7DOxt3f9FukQ4Qjyef3j9C2bfAAH4wd4oanSiqgM=; b=zQ5SFdgRZaS1X8B0S376FVBC2UGbmP/7NSVWh0bVvMtmr9YFxOaQrKnP4oDWAdWVDn ZKdiYE98u/amzO9mEjm5JW7yck/0Xm6Qbj4JrrSV6cN3DitSRm5kzagF5FPcrisgrycX 4qOGyqSWvRMr3gNddi8NK/6jNnJxbAleL6RXmsDcIFA+EmhUoACriTzTR6EeSqlARl7R hKpvX0yTX1TSr7zYwg3C3OWoSD5khbiDiqt5NBvfsYGndatkxfm1ki93RdEHy1j1mUPL FYKm1zi4zZiRQOfvrI+yJftM0zTrEEDD9kn0+SpA37Plf4JlBeUrJHMdRfjG5FHUtUm/ qCDQ== X-Gm-Message-State: AOAM530k1ETf5Cs/5HjuTyA74wKWzcqgKuba989nIeGWj5X7K5dWvCzv vnpd41qPuIE+zZxXVUglZ8A= X-Google-Smtp-Source: ABdhPJzou5nJlmfM5QPPdLgukU8Pqa9kdcUKBFhX7NA1Psh4UWPk+PAIFiTUH2zJk1+2RFtjhO/81Q== X-Received: by 2002:adf:f583:: with SMTP id f3mr8453319wro.116.1633038543971; Thu, 30 Sep 2021 14:49:03 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id o3sm4071686wra.52.2021.09.30.14.49.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Sep 2021 14:49:03 -0700 (PDT) Message-ID: <0541a55a86b604ec45980341ea64ace7b9312db3.camel@gmail.com> Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) From: Liliana Marie Prikler To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Thu, 30 Sep 2021 23:49:02 +0200 In-Reply-To: <87wnmx3jx3.fsf@gnu.org> 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> <87r1d64gd3.fsf_-_@gnu.org> <735304d110f5e99c66904fc7ced3465bf1815baf.camel@gmail.com> <87wnmx3jx3.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) 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: -1.0 (-) Hi, Am Donnerstag, den 30.09.2021, 22:09 +0200 schrieb Ludovic Courtès: > Liliana Marie Prikler skribis: > > > [...] > > Which is a practical issue because it'd mean that the tarball gets > > built as soon as the source is interpreted? > > It’s impractical because typical usage introduces top-level circular > references (e.g., if you write #$gzip). Ah, right. > > I mean that we don't need to wrap local-file inside an origin for > > example whereas we do need to wrap e.g. svn-fetch instead of having > > an svn-checkout constructor at the top. It's not really that > > noticable normally, but weird once you start thinking a little too > > hard about it. > > Hmm yeah, I must not be thinking hard enough. :-) Perhaps it's just me who finds it weird tho. ¯\_(ツ)_/¯ > > Slightly similar, but I don't think I'd want a singular source > > url. Instead > > > > (define-record-type* computed-tarball > > make-computed-tarball > > computed-tarball? > > this-computed-tarball > > (sources computed-tarball-sources) ; list of origins, local > > ; files or other things > > (builder computer-tarball-builder (thunked)) ; gexp > > (name computed-tarball-name) ; perhaps? > > (location computed-tarball-location (innate) > > (default (current-source-location)))) > > > > At the start of BUILDER, SOURCES are already unpacked to the > > current working directory under their stripped file names. After > > builder returns, we either package the contents of the current > > working directory up into a tarball (variant A) or we have builder > > return a list of files to pack up (variant B) which we then post- > > process maybe. > > > > WDYT? > > Overall LGTM! IWBN to see if there are other potential users in the > tree (I can’t think of any), but for IceCat and Linux-libre, it could > already improve the situation. Concrete examples which currently use "unpack more after unpack": - chez-scheme with nanopass and stex - xen's mini-os - lbzip2's gnulib (and probably gnulib in other locations) - similarly libgd in gedit and gnome-recipes (same origin for both) The builder for those would always be a simple (series of) directory rename(s) as well :) This list might not be complete, at least I haven't checked whether it is. Also, packages which have (package-source some-other-package) as input somewhere don't count here, as the missing sources can trivially be found and inserted imo. Regards, Liliana From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 18:17:12 2021 Received: (at 50620-done) by debbugs.gnu.org; 30 Sep 2021 22:17:12 +0000 Received: from localhost ([127.0.0.1]:54268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mW4MZ-00083R-V7 for submit@debbugs.gnu.org; Thu, 30 Sep 2021 18:17:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mW4MX-00083E-Ec for 50620-done@debbugs.gnu.org; Thu, 30 Sep 2021 18:17:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34444) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mW4MS-0007gL-89; Thu, 30 Sep 2021 18:17:04 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=36456 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mW4MR-0003yl-VZ; Thu, 30 Sep 2021 18:17:04 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: zimoun Subject: Re: bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) References: <20210916114505.2686370-1-zimon.toutoune@gmail.com> <20210916114734.2686426-1-zimon.toutoune@gmail.com> Date: Fri, 01 Oct 2021 00:17:01 +0200 In-Reply-To: <20210916114734.2686426-1-zimon.toutoune@gmail.com> (zimoun's message of "Thu, 16 Sep 2021 13:47:33 +0200") Message-ID: <877dex1zfm.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-done Cc: 50620-done@debbugs.gnu.org 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 (---) zimoun skribis: > The 'computed-origin-method' had been introduced as a workaround limitati= ons > in the 'snippet' mechanism. The procedure is duplicated which makes hard= to > automatically detects packages using it. > > * guix/packages.scm (computed-origin-method): Move procedure from... > * gnu/packages/gnuzilla.scm: ...here and... > * gnu/packages/gnuzilla.scm: ...there. I tweaked the commit log and applied, thanks! Hopefully we=E2=80=99ll grow a =E2=80=9Cproper=E2=80=9D solution thanks to = the discussions about & co. that we=E2=80=99ve had. Thanks everyone, Ludo=E2=80=99. From unknown Sat Sep 20 08:59:29 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 29 Oct 2021 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator