Skip to content

Revert "ocamlPackages.tcpip: 6.0.0 -> 6.1.0"#117738

Merged
vbgl merged 1 commit into
NixOS:masterfrom
sternenseemann:revert-tcpip
Mar 27, 2021
Merged

Revert "ocamlPackages.tcpip: 6.0.0 -> 6.1.0"#117738
vbgl merged 1 commit into
NixOS:masterfrom
sternenseemann:revert-tcpip

Conversation

@sternenseemann
Copy link
Copy Markdown
Member

TL;DR: tcpip in nixpkgs was updated before the release hit the opam-repository. Due to some issues on opam-repository's CI the 6.1.0 release was re-released (under the same version number) multiple times and ultimately withdrawn.

As a result the 6.1.0 we use in nixpkgs doesn't exist anymore and “officially” 6.0.0 is the newest release for tcpip.


This reverts commit 988f5a5.

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:
ocaml/opam-repository#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:
ocaml/opam-repository#18357 (comment)

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.

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

This reverts commit 988f5a5.

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:
ocaml/opam-repository#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:
ocaml/opam-repository#18357 (comment)

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.
@sternenseemann sternenseemann requested a review from vbgl March 27, 2021 00:10
@github-actions github-actions Bot added the 6.topic: ocaml OCaml is a general-purpose, high-level, multi-paradigm programming language. label Mar 27, 2021
@ofborg ofborg Bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Mar 27, 2021
@vbgl vbgl merged commit b2eb2c8 into NixOS:master Mar 27, 2021
@sternenseemann sternenseemann deleted the revert-tcpip branch March 27, 2021 14:35
@sternenseemann sternenseemann restored the revert-tcpip branch July 24, 2021 13:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: ocaml OCaml is a general-purpose, high-level, multi-paradigm programming language. 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants