[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#51307] Content hashes and file tree serialization methods
From: |
Ludovic Courtès |
Subject: |
[bug#51307] Content hashes and file tree serialization methods |
Date: |
Sun, 31 Oct 2021 15:48:16 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
zimoun <zimon.toutoune@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’.
[bug#51307] [PATCH 0/2] guix hash: eases conversion, Ludovic Courtès, 2021/10/30