[opam.2.1.0~beta4] Migration from 2.0 removes all constraints in the invariant

[kit-ty-kate]

$ opam-2.0 switch
#   switch  compiler                    description
->  4.11    ocaml-base-compiler.4.11.1  4.11
$ opam-2.1 switch invariant
["ocaml-base-compiler"]

This is a problem. This should results in ["ocaml-base-compiler" {= "4.11.1"}] instead.

[kit-ty-kate]

Somewhat related to #4333

[AltGr]

The code is here:

opam/src/state/opamSwitchState.ml

Lines 136 to 141 in beb696e

	if n <= 1 then
	OpamFormula.Atom (nv.name, Empty)
	else if nv = OpamPackage.Set.max_elt versions then
	OpamFormula.Atom (nv.name, Atom (`Geq, nv.version))
	else
	OpamFormula.Atom (nv.name, Atom (`Eq, nv.version))

So basically this should only happen if 4.11.1 was the only available version of ocaml-base-compiler, in which case we assume there was no need for a constraint. That should not be the case, unless maybe the package was pinned ?
Or maybe there was some trimming code taking place and marking packages conflicting with the base, hence unavailable and leading to make them unseen here ? But that code has been removed since:

opam/src/state/opamSwitchState.ml

Lines 886 to 892 in beb696e

	let u_available =
	(* TODO: removing what conflicts with the base is no longer correct now that
	we use invariants instead. Removing what conflicts with the invariant
	would be much more involved, but some solvers might struggle without any
	cleanup at this point *)
	(* remove_conflicts st base *)
	(Lazy.force st.available_packages)

(this is now handled in a much better way at the Cudf level)

[dra27]

(Discussed at the dev meeting on 26 Feb)

docker-base-images constructs an opam 2.0 root and builds a switch with ocaml-base-compiler. It then pins the package. An opam 2.1 binary is included in the Docker images and what happens here is that the repo upgrade sees the pin and so ignores the underlying base package version (by design).

It would be possible, but not trivial, for the repo upgrade to ignore the pin, but this would at least require resolving the switch and as it adds non-trivial complexity to an already non-trivial process, we decided that it's likely that docker-base-images is the only place this will be seen (and it will cease being visible when the image only contains an opam 2.1 binary).