_Correct_ trying to be too clever when upgrading switches from opam 2.0 #5176
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kit-ty-kate
approved these changes
Jul 14, 2022
rjbou
force-pushed
the
fix-invariant-upgrade
branch
from
5cca215 to
7defea4
Compare
kit-ty-kate
reviewed
Jul 20, 2022
kit-ty-kate
force-pushed
the
fix-invariant-upgrade
branch
from
7defea4 to
5e6fe4a
Compare
kit-ty-kate
reviewed
Jul 21, 2022
dra27
force-pushed
the
fix-invariant-upgrade
branch
from
d71430b to
6eb681c
Compare
rjbou
approved these changes
Jul 22, 2022
rjbou
force-pushed
the
fix-invariant-upgrade
branch
from
6eb681c to
5c826b4
Compare
When inferring a switch invariant from base packages, opam filtered out alternate versions of any package which is pinned. This causes all pinned packages to appear to be unique versions and so they are then inferred without constraint. Pinned packages are no longer filtered when inferring the invariant - only availability is used.
rjbou
force-pushed
the
fix-invariant-upgrade
branch
from
bc4cb08 to
0adbc1f
Compare
rjbou
added a commit
to rjbou/opam
that referenced
this pull request
Jul 26, 2022
_Correct_ trying to be too clever when upgrading switches from opam 2.0
Merged
This was referenced Sep 5, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternate approach from #5002 for fixing #4501.
When upgrading a switch from opam 2.0, opam needs to convert a list of base packages to a switch invariant. The process used for that applies three heuristics for package
foo.version:fooavailable, then the invariant"foo"is used (i.e. with no version)versionis the latest, then the invariant"foo" {>= "version"}is used (lower-bound with upgrades)"foo" {= "version"}is used (exactly equivalent)All this is attempting to reconstruct whether the user originally ran
opam switch create my-switch foooropam switch create my-switch foo.version. There are two intentions:If we had the chance to turn back the clock, I think intention 1 is a mistake - it's not stable over time (e.g. until 14 June 2022,
ocaml-base-compiler.4.14.0would have inferred"ocaml-base-compiler" {>= "4.14.0"}but now that there's an alpha release of OCaml 5, it would instead infer"ocaml-base-compiler" {= "4.14.0"}) and it's very difficult to be sure that's what the user actually meant, anyway. Intention 2, on the other hand, is a big usability improvement and was a headline reason for adding switch invariants in the first place - system compiler upgrades are basically a mess in opam 2.0, but as long as you end up with"ocaml-system"as the switch invariant, they work as expected in 2.1+.The bug seen on the base images in #4501 I think is simply an accident of #3894 when invariants were added. The set of available package versions was already present as part of depext updating, and the trim of non-pinned versions makes sense there. The fix I propose here, therefore, is to fix the original code only: when computing the invariant, don't filter out the other versions of a pinned package.
I've tested this in Docker for both the original bug and a system compiler upgrade.
It's tempting to eliminate the
>=heuristic completely, but on the basis that we haven't (I think) had any bug reports about it, I think it's probably better to have 2.1 and 2.2 both do the same (slightly odd) thing, than have the 2.0-2.1 upgrade differ from the 2.0-2.2 upgrade. In the future, I think this heuristic would be much better as a hint - e.g. haveopam switch create system ocaml-system.4.14.0emit a warning that you probably meant"ocaml-system"as the invariant, but that's for another day.