[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat)
From: |
Ludovic Courtès |
Subject: |
[bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat) |
Date: |
Thu, 30 Sep 2021 22:09:12 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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’.
- [bug#50620] [PATCH 1/2] guix: packages: Document 'computed-origin-method'., (continued)
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Ludovic Courtès, 2021/09/29
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Liliana Marie Prikler, 2021/09/29
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Ludovic Courtès, 2021/09/29
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Liliana Marie Prikler, 2021/09/29
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Ludovic Courtès, 2021/09/30
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Liliana Marie Prikler, 2021/09/30
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat),
Ludovic Courtès <=
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Liliana Marie Prikler, 2021/09/30
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Mark H Weaver, 2021/09/29
- [bug#50620] [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Ludovic Courtès, 2021/09/29
bug#50620: [PATCH 0/2] Unify 'computed-origin-method' (linux, icecat), Ludovic Courtès, 2021/09/30