Avoid trying to be too clever when upgrading switches from opam 2.0

[kit-ty-kate]

trafficstars

Fixes https://github.com/ocaml/opam/issues/4501 See https://github.com/ocurrent/opam-repo-ci/pull/148 See https://github.com/ocurrent/docker-base-images/pull/150

I don’t see any good reason for trying to guess what the user meant instead of letting the user choose what they want afterward.

Transforming a 2.0 switch to "<compiler-package>" (without constraint) is dangerous (as shown above) Transforming a 2.0 switch to "<compiler-package>" {>= "<current-version>"} is equally dangerous as it breaks switches named after its current compiler if the compiler is the latest. We can’t assume people with the latest compiler always want the latest

[AltGr]

I don't really have an opinion on removing the magic... the cases pointed out in the above are very specific to a convoluted CI setup, and the code might still be helpful for normal users (the "remove the constraint" part was intended for system compilers, where I think it results in a better UX) ; then again, magic is bad in general and being conservative as proposed ensures that the behaviour remains similar after the opam version bump.

In the end my main worry is that it may be late to change this: we may start having the issue of both choices , depending on the migration path followed by the user...

[dra27]

As noted in the end of the description in #5176, if we got to do the upgrade process, we'd probably opt to skip have the >= invariant trick, but it seems better to have 2.0->2.1 and 2.0->2.2 do the same upgrade, so we'll leave the main bug as fixed by #5176