如何查询特定GNU Guix存储项的构建相关信息？

我在使用GNU Guix系统一段时间后，发现/gnu/store/目录里出现了多个版本号同为guile-3.0.9/的目录：

ls -p /gnu/store | grep 'guile-3.0.9/'
10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9/
4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/
84rvhd3j7pfqrh7717cv7ddv2dc8xad5-guile-3.0.9/
g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/
rabsjkkm22xhz1vr5dh7r4ai98zprywx-guile-3.0.9/
sg2csvgqqc8r6519pyaqk6c4l1plh40f-guile-3.0.9/

这些目录的base32哈希前缀不同，说明它们的构建输入存在差异。我想获取这些存储项的具体信息，比如：

• 构建时间
• 版本新旧
• 构建输入内容
• 存在于存储目录的原因

我一直使用substitute服务器，尝试从ci.guix.gnu.org查询信息，但只找到了其中一个存储项的构建记录，其他的都查不到。想请教：拿到一个GNU存储项后，该通过什么方式、从哪些渠道获取它的关联信息？

PS：我知道其中部分是无效项，运行guix gc会被垃圾回收。

一、本地查询命令（最直接可靠） #

Guix自带工具可以直接从本地读取存储项的元数据，无需依赖外部服务器：

1. 查看基础元数据 #

用guix show命令，传入存储项的完整路径或哈希前缀：

guix show /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

会返回包版本、依赖列表、构建时间、维护者等核心信息，还能看到对应的derivation（构建配方）文件路径。

2. 分析构建输入与配方 #

• 查看直接依赖：

guix gc --references /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

• 查看完整构建配方（包括所有输入、环境变量、构建步骤）：

# 查看原始推导文件
cat $(guix gc --derivation /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9)
# 或格式化输出
guix derivation show /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

3. 获取构建时间与验证信息 #

• 用guix gc查看签名、构建时间等验证数据：

guix gc --verify /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

• 快速查看目录修改时间（通常等于构建完成时间）：

stat /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

4. 追踪存储项的引用来源 #

想知道这个存储项为什么出现在系统里，用guix gc --referrers查看引用它的对象：

guix gc --referrers /gnu/store/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

如果是被系统配置引用，可结合guix system search和配置文件进一步排查。

二、外部服务器查询补充 #

如果本地没有保留完整元数据（比如仅通过substitute下载、未保存推导文件），可以尝试：

1. 调用Guix HTTP API #

向substitute服务器发送请求获取存储项信息：

curl -H "Accept: application/json" https://ci.guix.gnu.org/nar-info/10p9mh0h11z2gs2z72lqnxq96ln6a5x7-guile-3.0.9

返回的JSON会包含哈希、依赖、构建时间等内容，部分服务器还会提供构建日志链接。

2. 排查Guix仓库提交历史 #

同版本包出现不同哈希，通常是因为包定义被修改（比如依赖更新、补丁调整）。可以在Guix Git仓库中搜索相关提交：

git clone https://git.savannah.gnu.org/git/guix.git
cd guix
git log --grep="guile-3.0.9"

对比不同提交的包定义差异，就能理解存储项不同的原因。

注意事项 #

• 未被任何活动引用的无效存储项，会被guix gc自动清理；若需保留，可用guix gc --add-roots标记为根引用。
• 部分substitute服务器可能未保存旧存储项的构建记录，此时本地查询是唯一可靠方式。

内容的提问来源于stack exchange，提问作者xiepan