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

["Ludovic Courtès" <ludo@gnu.org>]

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Donnerstag, den 30.09.2021, 10:28 +0200 schrieb Ludovic Courtès:
>> [...]
>> > 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.)
> Which is a practical issue because it'd mean that the tarball gets
> built as soon as the source is interpreted?

It’s impractical because typical usage introduces top-level circular
references (e.g., if you write #$gzip).

> I mean that we don't need to wrap local-file inside an origin for
> example whereas we do need to wrap e.g. svn-fetch instead of having an
> svn-checkout constructor at the top.  It's not really that noticable
> normally, but weird once you start thinking a little too hard about it.

Hmm yeah, I must not be thinking hard enough.  :-)

> Slightly similar, but I don't think I'd want a singular source url. 
> Instead
>
>   (define-record-type* <computed-tarball> computed-tarball 
>     make-computed-tarball
>     computed-tarball?
>     this-computed-tarball
>     (sources  computed-tarball-sources)  ; list of origins, local 
>                                          ; files or other things
>     (builder  computer-tarball-builder (thunked)) ; gexp
>     (name     computed-tarball-name) ; perhaps?
>     (location computed-tarball-location (innate) 
>               (default (current-source-location))))
>
> At the start of BUILDER, SOURCES are already unpacked to the current
> working directory under their stripped file names.  After builder
> returns, we either package the contents of the current working
> directory up into a tarball (variant A) or we have builder return a
> list of files to pack up (variant B) which we then post-process maybe.
>  
> WDYT?

Overall LGTM!  IWBN to see if there are other potential users in the
tree (I can’t think of any), but for IceCat and Linux-libre, it could
already improve the situation.

Thanks,
Ludo’.