[bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat)

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

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?