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

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Mark H Weaver <mhw <at> netris.org>, 50620 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com>
Subject: [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat)
Date: Thu, 30 Sep 2021 10:28:24 +0200

Hi!

Liliana Marie Prikler <liliana.prikler <at> gmail.com> 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’s a lot going on there, though that’s partly because it’s
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’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.)

>> > 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: <package>,
>> <origin>, <operating-system>.  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
>> <origin> came to be (we could have used <package> 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?

> 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
<computed-tarball> 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> computed-tarball make-computed-tarball
    computed-tarball?
    this-computed-tarball
    (url      computed-tarball-url)  ;or could be an <origin>
    (builder  computer-tarball-builder (thunked)) ;gexp
    (location computed-tarball-location (innate) (default (current-source-location))))

Is this what you had in mind?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.