Release management can be a real pain.
I normally do all of these steps in a single pass with the aid of a script:
- Tag the commit using
- Create a GitHub Release on this tag.
- Upload the tarball generated by
cabal sdistto Hackage.
However, this one instance I decided to do the Hackage release later out of caution. But this “cautionary measure” ended up causing more problems than it solved, because I went off-script and disrupted my usual tried-and-tested workflow.
Normally a GitHub Release includes:
- A tarball automatically generated by GitHub from the Git tree
- A tarball generated by running
cabal sdist, attached as a “binary”
But somehow for version 18.104.22.168 my upload script failed to attach the
Later when I wanted to upload to Hackage, I thought it’d be a good idea to use the original
sdist-generated tarball that contained the original timestamps on the files. So, I habitually downloaded the first tarball link I saw on the GitHub Release page for 22.214.171.124. Obviously that was not the
sdist-generated tarball, it was the one auto-generated by GitHub.
At first, Hackage complained that the tar format was not ustar. That itself should’ve aroused suspicion, since
cabal sdist always generates them in ustar format, but I didn’t pay attention.* Instead, I extracted the tarball and re-made the archive in ustar format.
The end result was that I accidentally uploaded a GitHub-generated tarball instead of an
sdist-generated tarball, which didn’t work because the Autoconf-generated
configure script was missing.
* I thought maybe GitHub was altering (“improving”) tarballs behind our backs. In retrospect that was a very silly idea.