Closed RalfJung closed 7 years ago
It's indeed a bug, which I could reproduce — thanks for the detailed report. The way opam 1.2.2 uses to detect package changes was not very reliable, and here it seems it gets confused by the pinning; this has already been fixed in the development branch for 2.0, where we keep track of the actual opam files used for installation, and compare them with their upstream to detect changes — I can confirm that the bug is no longer there.
As a workaround, you could remove the $(opam config var prefix)/reinstall
file after update
to make opam forget about pending reinstallations.
By the way, caching a preliminary opam switch is a good approach, that I use for opam itself
Great to here the bug got fixed!
As a workaround, you could remove the $(opam config var prefix)/reinstall file after update to make opam forget about pending reinstallations.
I assume that would mean that if there is an actual upstream update, it would be missed?
I assume that would mean that if there is an actual upstream update, it would be missed?
Unfortunately, yes.
Steps to reproduce
Run the following script twice:
Expected behavior
On the second run, nothing is compiled because everything is already in the correct version
Actual behavior
coq
(and its reverse dependencies) are recompiled on the second run:On the third and following runs, no more recompilation happens.
Context
I am using this script to set up the build dependencies of a project for a CI build. The
opamroot
folder is cached between CI runs so that build dependencies are not unnecessarily re-compiled. However, due to this bug, when I clear the CI cache, it takes two CI runs until the following runs are fast and properly re-use build dependencies.opam config report