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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

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: <http://issues.guix.gnu.org/50620#0>
> 
> 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] <http://issues.guix.gnu.org/50515#4>