Time at which hackage-overlay-repo-tool is run leaks into package tarballs
Despite 72dd0b56, the time at which the head.hackage
index is generated appears to leak into package tarballs. This manifests when trying to download a package with a head.hackage
patch:
$ cabal repl -b acid-state
Resolving dependencies...
Build profile: -w ghc-8.9.0.20191110 -O1
In order, the following will be built (use -v for more details):
- filelock-0.1.1.3 (lib) (requires download & build)
- network-3.1.0.1 (lib:network) (requires build)
- network-bsd-2.8.1.0 (lib) (requires build)
- acid-state-0.16.0 (lib) (requires download & build)
- staging-0.1.0.0 (lib) (configuration changed)
Downloading filelock-0.1.1.3
Starting network-3.1.0.1 (all, legacy fallback)
Downloading acid-state-0.16.0
Downloaded acid-state-0.16.0
Building network-3.1.0.1 (all, legacy fallback)
Installing network-3.1.0.1 (all, legacy fallback)
Completed network-3.1.0.1 (all, legacy fallback)
cabal: Failed to download filelock-0.1.1.3 (which is required by
staging-0.1.0.0). The exception was:
Invalid hash for <repo>/package/filelock-0.1.1.3.tar.gz
Running scripts/head.hackage.sh update
fixes the issue, but due to the changed timestamps in each package tarball, trying to build any patched library will result in a cache miss and therefore must be rebuilt from scratch.
(I'm opening an issue here after discussing this with @bgamari.)