GNU bug report logs - #51307
[PATCH 0/2] guix hash: eases conversion

Previous Next

Full log

Message #41 received at 51307 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 51307 <at> debbugs.gnu.org
Subject: Content hashes and file tree serialization methods
Date: Sun, 31 Oct 2021 15:48:16 +0100

zimoun <zimon.toutoune <at> gmail.com> skribis:

>> That’s expected: ‘--recursive’ uses a different computation method,
>> including file metadata (technically, it serializes the file as a nar
>> and computes the hash of the nar).
>
> Yes, but that’s odd.  It should be the same computation method for
> tarballs.  Nothing is recursive for a tarball

Thinking more about it, I think confusion stems from the term
“recursive” (inherited from Nix) because, as you write, it doesn’t
necessarily have to do with recursion and directory traversal.

Instead, it has to do with the serialization method.

Thus, probably, ‘--recursive’ could be replaced by a ‘-S’ flag:

  guix hash -S nar something

or:

  guix hash -S none something
  guix hash -S git something
  guix hash -S swh something

‘-S none’ would be like not passing ‘-r’; ‘-S git’ would serialize the
file/directory as a Git tree; ‘-S swh’ would serialize it the SWH way,
which is like Git except it preserves empty directories (Disarchive
implements the Git/SWH methods already.)

Thoughts?

As mentioned towards the end of
<https://guix.gnu.org/en/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/>,
being able to deal with different tree serialization methods would be
useful going forward; for instance, if we had the option to store
SWH-style content hashes for origins, that’d help a lot.  Allowing ‘guix
hash’ to deal with that is a first step in that direction.

(Apologies for slipping a bit off-topic…)

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.