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. ;-)