Inconsistent state in the hackage mirror

[poscat0x04]

问题描述 / Bug description

The hash of 01-index.tar.gz does not match the hash specified in snapshot.json.

[taoky]

https://github.com/ustclug/ustcmirror-images/blob/cf2948df0c2b7175c1dc91c8fd1a5bacb65b2c01/hackage/sync.sh#L21-L31

01-index.tar.gz 有 120+ MB 大，可能是下载较慢，然后在下载的途中 01-index.tar.gz 发生了变化。目前将同步的出口从移动调整到了联通，速度快很多，但是仍然没法根本上解决问题。

我没有很好的解决思路，加上 checksum 和重试的逻辑会让同步脚本过分复杂，目前来看还不如等下一次同步让它自己更新。如果你有解决方法的话直接交 PR 吧。

[taoky]

想到了一个思路：先下载比较小的 snapshot，下载完之后立刻下载 01，来减小 01 更新的时间差。

[poscat0x04]

似乎 cabal 在下载这个 tarball 的时候是 incremental 的
（不知道是怎么实现的）

[poscat0x04]

其实可以直接用 cabal

[taoky]

其实可以直接用 cabal

怎么使用呢？是否有使用 cabal 做镜像同步的相关文档？

[poscat0x04]

运行 cabal update 会在 ~/.cache/cabal/packages/<repo name> (assuming 最新版本 cabal) 下创建如下文件:

对应的 ~/.config/cabal/config:

repository tuna
  url: https://mirrors.tuna.tsinghua.edu.cn/hackage/
  secure: True

jobs: $ncpus

前缀 ~/.cache/cabal/packages 可以通过 remote-repo-cache 选项来更改

之后每次按照相同的配置运行 cabal update 应该都是增量更新

https://github.com/ustclug/ustcmirror-images/blob/cf2948df0c2b7175c1dc91c8fd1a5bacb65b2c01/hackage/sync.sh#L18-L31 应该可以替换掉这些

[taoky]

感谢，我今天有时间的话试一下。

[poscat0x04]

似乎 cabal 在下载这个 tarball 的时候是 incremental 的 （不知道是怎么实现的）

原来是因为两个合法的 gzip stream 可以 concat 成一个合法的 gzip stream

[taoky]

考虑之后还是觉得用 cabal 的方法不太合适，因为 cabal 更新之后会产生一个可能比较长的时间差：metadata 是最新的，但是包还没有同步完成。差分同步的必要性可能也不是那么大，考虑到同步的频率是每天一次，每天下载 ~120M 的内容也不是什么很大的问题。

[poscat0x04]

是不是可以 cp --reflink 出来再 mv 回去 🤔