Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification: behavior of interaction between opam pin --kind version and opam pin --kind path #3983

Open
maroneze opened this issue Sep 12, 2019 · 1 comment
Projects

Comments

@maroneze
Copy link
Contributor

(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:

$ opam pin add frama-c <file.tar.gz>

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:

$ opam pin add frama-c 19.0
Package frama-c is already pinned to file://<path_to_file.tar.gz> (version 19.0).
Unpin and continue? [Y/n] Y
frama-c is now pinned to version 19.0

The following actions will be performed:
  ↻ recompile frama-c 19.0
Do you want to continue? [Y/n] Y

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.

@rjbou
Copy link
Collaborator

rjbou commented Sep 20, 2019

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

  • pinned
  • & if the source has already been get
  • & if the package version matches the source package version.

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.

@dra27 dra27 added this to To do in Opam 2.2.0 via automation Jul 16, 2021
@dra27 dra27 moved this from To do to Bump to 2.3? in Opam 2.2.0 Jan 13, 2022
@dra27 dra27 removed this from Bump to 2.3? in Opam 2.2.0 May 17, 2022
@dra27 dra27 added this to To do in Opam 2.3 via automation May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Opam 2.3
  
To do
Development

No branches or pull requests

3 participants