[bug#50620] [PATCH 1/2] guix: packages: Document 'computed-origin-method'.

[zimoun]

Hi,

On Tue, 28 Sept 2021 at 19:24, Liliana Marie Prikler
<liliana.prikler@gmail.com> 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!

--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-…" and not "firefox-…", and similarly
for'linux-libre'.
--8<---------------cut here---------------end--------------->8---

0: <http://issues.guix.gnu.org/50515#3>
1: <http://issues.guix.gnu.org/50515>

> > > 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
<https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00106.html>
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. ;-)