[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transform options: check if applied or not
From: |
Maxime Devos |
Subject: |
Re: Transform options: check if applied or not |
Date: |
Thu, 09 Sep 2021 12:32:24 +0200 |
User-agent: |
Evolution 3.34.2 |
zimoun schreef op do 09-09-2021 om 00:29 [+0200]:
> Why? It is fixed-output so I was expecting the same thing. And the
> same as:
>
> --8<---------------cut here---------------start------------->8---
> $ guix download https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz
>
> Starting download of /tmp/guix-file.qkhxkp
> From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz...
> following redirection to
> `https://mirrors.sarata.com/gnu/hello/hello-2.10.tar.gz'...
> …10.tar.gz 709KiB 549KiB/s 00:01
> [##################] 100.0%
> /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
> 0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
> --8<---------------cut here---------------end--------------->8---
>
> Why the store item of source tarball is it different when applying the
> transformation?
There is one situation I know of where this can happen, though that's
for 'local-file' and not 'upstream-source-compiler': one has #:recursive? #t
and the other has #:recursive? #f.
‘download-to-store’ (used indirectly by upstream-source-compiler) sets
#:recursive? #false
by default. built-in-download (used by url-fetch) sets #:recursive? #false
too, unless
the file is expected to be executale.
This doesn't explain what's going on here (as #:recursive? is #f in both cases),
but maybe it gives an idea where to look?
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part