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.