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

[Liliana Marie Prikler]

Hi,

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?

> > > > 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?
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.

> > 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?
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?