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

Previous Next

Full log

Message #98 received at 50620 <at> debbugs.gnu.org (full text, mbox):

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

Hi,

Am Donnerstag, den 30.09.2021, 22:09 +0200 schrieb Ludovic Courtès:
> Liliana Marie Prikler <liliana.prikler <at> gmail.com> skribis:
> 
> > [...]
> > 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).
Ah, right.

> > 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.  :-)
Perhaps it's just me who finds it weird tho.  ¯\_(ツ)_/¯

> > 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.
Concrete examples which currently use "unpack more after unpack":

- chez-scheme with nanopass and stex
- xen's mini-os
- lbzip2's gnulib (and probably gnulib in other locations)
- similarly libgd in gedit and gnome-recipes (same origin for both)

The builder for those would always be a simple (series of) directory
rename(s) as well :)

This list might not be complete, at least I haven't checked whether it
is.  Also, packages which have  (package-source some-other-package) as
input somewhere don't count here, as the missing sources can trivially
be found and inserted imo.

Regards,
Liliana

Previous Next

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