Open maroneze opened 5 years ago
You face here a corner case. Pin and install action are two different actions, and on install, the rule for opam to check if it should take the already present specific source (pinned) or retrieve an archive is to check if the package is
As it is the same version, your second pinning complies to all those check, so opam don't fetch the source as it is considered as already present.
On unpinning, opam don't remove internally stored sources, @AltGr any reason for that? I suppose that it is to minimize operation, and keeps it to opam clean
action.
(This is a question about a somewhat unintuitive behavior related to
opam pin
; sorry if it is already mentioned somewhere.)One user of our opam package used a
opam pin --kind path <file.tar.gz>
to install a custom release whose version number is identical to the "official" release (frama-c 19.0). They proceeded as follows:The package was path-pinned to version 19.0. Then they noticed an issue and wanted to install the "official" package from opam, so they did as they were used to:
He expected the new version to be that of the official opam repository, but opam in fact recompiled the same path-pinned package. I could reproduce it with opam 2.0.4.
My question is: is this intended behavior? I'm asking in case it might not be. I agree that having a custom
.tar.gz
with the same version number is not ideal, and possibly part of the issue, but still, I'd have expected that, when re-pinning a package, opam would not consider the soon-to-be-unpinned packages among the possible candidates.