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 git-tag
• Create a GitHub Release on this tag.
• Upload the tarball generated by cabal sdist to 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 1.2.6.1 my upload script failed to attach the sdist-generated tarball.

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 1.2.6.1. 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.