This reverts commit 988f5a5910.
The release process for many OCaml packages and in extension mirage
related packages usually entails creating a release in the respective
own repository so a release tarball becomes available and then opening a
PR against ocaml/opam-repository to finalize the release. During this
new issues can be discovered which push the release back.
This happened for mirage-tcpip 6.1.0 several times:
https://github.com/ocaml/opam-repository/pull/18357
Prompting in total 3 different 6.1.0 releases with different hashes
respectively (the hash for ocamlPackages.tcpip.src shouldn't be
reproducible anymore, but we probably have cached the tarball already).
Ultimately the PR to opam-repository was closed to investigate some
failures on opam-repository's CI and the release postponed:
https://github.com/ocaml/opam-repository/pull/18357#issuecomment-808434285
I jumped the gun with the release and updated tcpip in nixpkgs before
tcpip was “properly” released in opam. I usually watch the github
repository of package I maintain for releases and can react pretty
quickly to a release as a result. Most of the time I also check
opam-repository's PRs nowadays for extra context or information, but
when everything seems fine and tests succeed I deem the update alright
to PR to nixpkgs. Being faster than opam was achievable in these cases
and actually seems kind of tantalizing.
In the light of this experience however, we should wait for the opam
PR getting merged at least for some packages that exhibit this behavior
of rereleasing the same version number multiple times to get the release
just right (afaik the 6.1.0 tag pointed to three different revisions for
tcpip). To me this is questionable upstream behavior we just have to deal
with in some way.
Ulrik Strid