freebsd-pkg：部分软件包的校验和与上游不符合

[ykla]

问题描述 / Bug description

根据 https://mirrors.ustc.edu.cn/freebsd-pkg/FreeBSD%3A14%3Aamd64/latest/packagesite.txz、https://mirrors.ustc.edu.cn/freebsd-pkg/FreeBSD%3A14%3Aamd64/latest/data.txz，以及实际在脚本中起判断作用的 https://mirrors.ustc.edu.cn/freebsd-pkg/FreeBSD%3A14%3Aamd64/latest/packagesite.txz：

{"name":"openjdk17","origin":"java/openjdk17","version":"17.0.16+8.1_4","comment":"Java Development Kit 17","maintainer":"java@FreeBSD.org","www":"https://openjdk.java.net/projects/jdk/17/","abi":"FreeBSD:14:amd64","arch":"freebsd:14:x86:64","prefix":"/usr/local","sum":"bbe335d05edebbbebe3d81a97053b25022c73f20980e033937fc2360346aec4f","flatsize":322603597,"path":"All/openjdk17-17.0.16+8.1_4.pkg","repopath":"All/openjdk17-17.0.16+8.1_4.pkg","licenselogic":"single","licenses":["GPLv2"],"pkgsize":165893853,"desc":"An open-source implementation of the Java Platform, Standard Edition,"

openjdk17 的 sha256 应为 bbe335d05edebbbebe3d81a97053b25022c73f20980e033937fc2360346aec4f，但是下载的 https://mirrors.ustc.edu.cn/freebsd-pkg/FreeBSD%3A14%3Aamd64/latest/All/openjdk17-17.0.16%2B8.1_4.pkg 校验和实为 fbb69747ad18a7451d23278d33b91cf6f3de9b94ca87d0b16d2ca9aadbcfc9f0

同时，使用官方源 pkg.freebsd.org 获取的 openjdk17 可以正常安装，其校验和同为 bbe335d05edebbbebe3d81a97053b25022c73f20980e033937fc2360346aec4f：

# sha256 /var/cache/pkg/openjdk17-17.0.16+8.1_4.pkg 
SHA256 (/var/cache/pkg/openjdk17-17.0.16+8.1_4.pkg) = bbe335d05edebbbebe3d81a97053b25022c73f20980e033937fc2360346aec4f

---

当前使用 USTC 报错如下：

root@ykla:/usr/ports/aur # pkg ins openjdk17
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        javavmwrapper: 2.7.10 [FreeBSD]
        openjdk17: 17.0.16+8.1_4 [FreeBSD]

Number of packages to be installed: 2

The process will require 308 MiB more space.
158 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching openjdk17-17.0.16+8.1_4.pkg: 100%  158 MiB  41.5MB/s    00:04    
pkg: cached package openjdk17-17.0.16+8.1_4: missing or size mismatch, fetching from remote
[2/2] Fetching openjdk17-17.0.16+8.1_4.pkg: 100%  158 MiB  55.3MB/s    00:03    
pkg: cached package openjdk17-17.0.16+8.1_4: missing or size mismatch, cannot continue
Consider running 'pkg update -f'
Fetching openjdk17-17.0.16+8.1_4.pkg: 100%  158 MiB  55.3MB/s    00:03    
pkg: cached package openjdk17-17.0.16+8.1_4: missing or size mismatch, fetching from remote
Fetching openjdk17-17.0.16+8.1_4.pkg: 100%  158 MiB  55.3MB/s    00:03    
pkg: cached package openjdk17-17.0.16+8.1_4: missing or size mismatch, cannot continue
Consider running 'pkg update -f'

此问题之前频繁发生，但我从未重视过。今天中午社区有人反馈，我刚才又复现了一遍。

[taoky]

可能的一种情况是：

1. 上游原地修改了一个包
2. 同步的过程中这个包获取到了新版本，因为名字没有变化，因此覆盖
3. 同步的过程因为 timeout 等原因被中断，也有可能上游再次出现了更新导致 hash 不一致

我没有好的解决方案。另外我注意到现在同步过程中我们有大量的请求收到了 429 响应：

[INFO] download http://pkg.freebsd.org/FreeBSD:15:amd64/quarterly/All/py311-diffoscope-306.pkg
[WARN] download failed http://pkg.freebsd.org/FreeBSD:15:amd64/quarterly/All/py311-diffoscope-306.pkg
curl: (22) The requested URL returned error: 429

这表明上游不欢迎我们的同步，视情况我们可能会撤下 freebsd-pkg 镜像。

[taoky]

另外目前下载失败的包会直接跳过，所以也有可能出现某个包因为下载失败还是老的情况。

[gaoyifan]

早前也遇到过类似的情况，上游的确会原地更新文件。后来给脚本增加了 hash 特性，理论上应该可以在很大程度上避免这个问题。 脚本会先查看 .by-hash/ 中是否存在对应文件，如果存在，则会创建硬链接；不存在，会下载后再创建链接。

从同步日志推测，应该是上游大量更新，完整同步的失败率变高，导致用户看到了中间状态所致。

一种缓解措施是，每次同步结束后清理掉与元信息中记录的hash不一致的文件，这样用户最差情况会看到404，而不是下载后才发现校验对不上。

[ykla]

早前也遇到过类似的情况，上游的确会原地更新文件。后来给脚本增加了 hash 特性，理论上应该可以在很大程度上避免这个问题。 脚本会先查看 .by-hash/ 中是否存在对应文件，如果存在，则会创建硬链接；不存在，会下载后再创建链接。

从同步日志推测，应该是上游大量更新，完整同步的失败率变高，导致用户看到了中间状态所致。

一种缓解措施是，每次同步结束后清理掉与元信息中记录的hash不一致的文件，这样用户最差情况会看到404，而不是下载后才发现校验对不上。

我有一个问题，如果上游原地更新（抱歉我不理解这个词，按字面意思解读），但是如果发生变动，元数据也必然会变动。问题在于元数据一开始就是最先被拉取更新的。同时旧包因为检验和不符也会被直接删除。如果原地更新应该会直接报错 404。现在上游和 USTC 现在的元数据都完全一致，说明并未发生原地更新。

他最后一步是根据之前新拉取的元数据把旧包删掉。那用户最终拉取的时候应该报错 404。

脚本的逻辑是把元数据从提供给用户的路径 A 复制到 B，然后先更新该目录 B 中的元数据，然后根据目录 B 中元数据挨个下载软件包到目录 A。循环下载。下载后把目录B中元数据复制到 A，覆盖其原有的元数据。再根据目录B的元数据检索目录 A 中不存在的软件包，进行删除。我不知道这种理解是否正确。

---

对于报错 429 通过 User-Agent 能否是一种可行的绕过方案？

pkg -vv 输出的 HTTP_USER_AGENT = "pkg/2.3.1"; 与抓包结果 pkg/2.3.1 相同

[gaoyifan]

@ykla
同步逻辑：

1. 下载元数据到临时目录
2. 更新软件包
3. 更新元数据
4. 清理无引用的文件

「原地更新」是指：软件包文件名不变，但内容变化。当然，对应的元数据中记录的hash也变化。

上述同步逻辑中存在一个风险： 如果第二步软件包更新更过程中发生错误（包括无法从重试恢复的错误），那么第三步是否要更新元数据？
这是一个tricky的问题，无论是否更新元数据都会存在某种不一致的风险。因为此时的软件包集合既与旧版元数据不一致，也与新版元数据不一致。
彻底的解决方案是利用诸如zfs snapshot特性，让元数据与软件包实现真正一致的原子性更新。但当前的同步框架不支持这种操作。

对于像是 Debian/RHEL 这类仓库，上游确保了不会出现软件包原地更新，也就是说同名的包文件永远不会发生内容改变，软件包更新必然伴随着文件名变化。因此多阶段同步是能够确保一致性的（只要不清理软件包，旧版元数据始终是一致的）。而freebsd-pkg坏就坏在会出现原地更新的情况😂

P.S. 当前不会清理hash不一致的文件。不过无论是否清理，用户都没法正常使用，差异只是404 / checksum mismatch.

[taoky]

其实因为网络原因，现在 freebsd-pkg 的同步已经很难追上上游了。我现在的想法是把 freebsd-pkg 改成和我们现在对 pypi/nix-channels/anaconda/flathub 类似的缓存的模式来提高一致性，缓解同步可能带来的不可用的问题：

• 包的元数据仍然正常同步
• Nginx 配置对不存在的包 302 重定向回上游
• 有一个每小时运行的程序读取 Nginx log 决定下载哪些文件（对于原地更新的问题，可以添加相关的逻辑检查）

由于最近七天 freebsd-pkg 的总流量不足 200GB，这样实现的话要下载的包的量可以小很多，更新缓存也可以更快，也可以节省磁盘空间。

[taoky]

目前同步最后添加了校验，hash 和 metadata 不一样的文件会被删除；访问不存在的 pkg 会被重定向到 pkg.freebsd.org。

[taoky]

我现在的想法是把 freebsd-pkg 改成和我们现在对 pypi/nix-channels/anaconda/flathub 类似的缓存的模式来提高一致性，缓解同步可能带来的不可用的问题

新的 cache 部署了。

[ykla]

我现在的想法是把 freebsd-pkg 改成和我们现在对 pypi/nix-channels/anaconda/flathub 类似的缓存的模式来提高一致性，缓解同步可能带来的不可用的问题

新的 cache 部署了。

可以的话，能不能仅针对季度分支和 latest 分支，不面向内核模块源及 pkgbase（即保证后者的原子更新与完整性） ？

[ykla]

根据 https://github.com/freebsd/poudriere/releases/tag/3.4.4 和 freebsd/poudriere@cdd7d7b

poudriere 解决了原地更新的 bug（给 pkg 文件名加上了哈希值，同时保留了旧文件），但是同时镜像结构发生了变化。

目前不知何时会部署到官方构建机器。