GNU bug report logs

#78649 (recursive? #t) doesn't seem to be part of the source hash

PackageSource(s)Maintainer(s)
guix PTS Buildd Popcon
Full log

Message #8 received at 78649@debbugs.gnu.org (full text, mbox, reply):

Received: (at 78649) by debbugs.gnu.org; 31 May 2025 10:13:23 +0000
From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 06:13:23 2025
Received: from localhost ([127.0.0.1]:55879 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1uLJDP-0001U4-3u
	for submit@debbugs.gnu.org; Sat, 31 May 2025 06:13:23 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:53016 helo=mail.ditigal.xyz)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rutherther@ditigal.xyz>)
 id 1uLJDK-0001TH-8W
 for 78649@debbugs.gnu.org; Sat, 31 May 2025 06:13:21 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 7e93040b
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Sat, 31 May 2025 10:13:10 +0000 (UTC)
From: Rutherther <rutherther@ditigal.xyz>
To: 78649@debbugs.gnu.org
Subject: Re: (recursive? #t) doesn't seem to be part of the source hash
In-Reply-To: <331afb8a-fa7f-4935-b990-ebd6f5268b58@nomike.com>
Date: Sat, 31 May 2025 12:13:08 +0200
Message-ID: <87v7phay17.fsf@ditigal.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
 i=@ditigal.xyz; q=dns/txt; s=20240917; t=1748686390; h=from : to : cc
 : subject : in-reply-to : date : message-id : mime-version :
 content-type : content-transfer-encoding : from;
 bh=qARculJpzgmEuCMpNg+3DRARG3xavyKJ8YXTc1pnoRQ=;
 b=LdD2n7Y9zTW2HDpD+whDXKPZDOK87C1Y8RhA5jzWsc9StSXG3I8YM57XIeb/j0lXT0Mfg
 yE1sb4MXMYWfRUGiS4Z9Rfn89RyThXOvZTMARfawSTzT2O3Sr+daSRFi/n71t2KXOdiLiqQ
 HTXonLTHgIuuFwXSWFSA6sM3qVDFN5s=
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  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 >  à [...]
    
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-Debbugs-Envelope-To: 78649
Cc: "nomike \(they/them\)" <nomike@nomike.com>
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  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 >  à [...]
    
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

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

Send a report that this bug log contains spam.

debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Mon Sep 8 22:05:09 2025; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.