GNU bug report logs -
#78649
(recursive? #t) doesn't seem to be part of the source hash
Previous Next
To reply to this bug, email your comments to 78649 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#78649
; Package
guix
.
(Fri, 30 May 2025 22:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"nomike (they/them)" <nomike <at> nomike.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Fri, 30 May 2025 22:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi!
I'm currently working on a package definition and again stumbled upon an
issue:
I had the flag `(recursive? #t)` added to `source`:
```scheme
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/openscad/openscad")
(commit commit)
(recursive? #t)))
(sha256
(base32 "1bkzrjjp0qvfg7pj24j5pa0i6zj0zsqjb5z4w3l6pjdb5q9in0qi"))
(file-name (git-file-name name version))))
```
I then removed the recursive flag and continued on working on my
package, which is based on a commit-ID of the upstream project. Once I
switched to a newer commit, I got strange build errors from cmake. I
switched back the original commit, everything worked again.
It took me a while to remember, that in such a case, guix is not
re-downloading the source as the source hash doesn't change.
IMHO this hash should also contain flags like recursive.
When `git clone foo` is changed to `git clone --recursive foo` the
source has obviously changed (unless the repo doesn't have submodules
perhaps), so it doesn't make sense that the sha256 hash stays the same.
Is this something we can address?
Or is this an issue as it would invalidate all current source hashes at
once?
Thanks
nomike
Information forwarded
to
bug-guix <at> gnu.org
:
bug#78649
; Package
guix
.
(Sat, 31 May 2025 10:14:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78649 <at> debbugs.gnu.org (full text, mbox):
Hi nomike,
> Hi!
>
> I'm currently working on a package definition and again stumbled upon an
> issue:
>
> I had the flag `(recursive? #t)` added to `source`:
>
> ```scheme
> Â Â Â Â Â (source
> Â Â Â Â Â Â (origin
> Â Â Â Â Â Â Â Â (method git-fetch)
> Â Â Â Â Â Â Â Â (uri (git-reference
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â (url "https://github.com/openscad/openscad")
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â (commit commit)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â (recursive? #t)))
> Â Â Â Â Â Â Â Â (sha256
> Â Â Â Â Â Â Â Â Â (base32 "1bkzrjjp0qvfg7pj24j5pa0i6zj0zsqjb5z4w3l6pjdb5q9in0qi"))
> Â Â Â Â Â Â Â Â (file-name (git-file-name name version))))
> ```
>
> I then removed the recursive flag and continued on working on my
> package, which is based on a commit-ID of the upstream project. Once I
> switched to a newer commit, I got strange build errors from cmake. I
> switched back the original commit, everything worked again.
> It took me a while to remember, that in such a case, guix is not
> re-downloading the source as the source hash doesn't change.
>
> IMHO this hash should also contain flags like recursive.
>
> When `git clone foo` is changed to `git clone --recursive foo` the
> source has obviously changed (unless the repo doesn't have submodules
> perhaps), so it doesn't make sense that the sha256 hash stays the same.
>
> Is this something we can address?
I don't think so. For FOD the store path is created from:
- path to gnu store
- hash of the derivation
- name of the package
So when speaking about origin, uri doesn't matter at all. Only file-name
and sha256 does.
That means it is responsibility of the user to change the hash to a new
one when nothing from those changes, but the source is supposed to
change. Ie. if commit is changed to different one without having it in
the file-name, if recursive is changed...
When you change the source, also change the hash to a correct one (or an
invalid one and let it fail to tell you new hash)
>
> Or is this an issue as it would invalidate all current source hashes at
> once?
Change like adding the uri to the creation of the hash would definitely
invalidate all source hashes. But it is exactly the point of FOD to not
depend on the uri. If uri is changed, but sha256 stays the same, that
implies the new uri is supposed to fetch the same source => no need for
a redownload.
>
> Thanks
>
> nomike
Rutherther
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.