Switching images to opam 2.1 by default

[dra27]

• set-opam-version.sh 2.1 added to images. It's just sudo ln -f /usr/bin/opam-$1 /usr/bin/opam && rm -rf ~/.opam && opam init -k local -a /home/opam/opam-repository --bare (with error handling!)
• opam-depext needs 2.1 support so that with OPAMCLI=2.0 opam depext package works
• Images have ENV OPAMCLI=2.0 and /usr/bin/opam is /usr/bin/opam-2.1 by default. The root is therefore opam 2.1

This presently blocked on the opam depext part, since there's no compatibility for previous versions. Switching to opam 2.1 will expose some uses to problems with opam's integrated depext on certain platforms.

I propose set-opam-version.sh does a re-init for consistency: it only does fractionally more than opam update would, but it's a more consistent thing to do when downgrading from 2.1 to 2.0.

[reynir]

Are there any updates on this? Since mirage 4 requires opam-version >= 2.1.0 this would be very convenient :-)

[reynir]

Ah, I see in #131 that /usr/bin/opam-2.1 is provided. Maybe the docker hub page can be updated to reflect this? Currently it claims the images come with the latest release of opam.

[reynir]

FWIW mirage expects opam in $PATH to be opam 2.1. Copying opam-2.1 to /usr/local/bin/opam works around this.

[kit-ty-kate]

yes, most of our CI projects start with:

FROM ocaml/opam:<tag>
RUN sudo ln -f /usr/bin/opam-2.1 /usr/bin/opam
RUN opam init --reinit -ni

[tmcgilchrist]

There is also a dev version of opam available if you do this:

FROM ocaml/opam:<tag>
RUN ln -f ~/local/bin/opam-dev ~/local/bin/opam
RUN opam init --reinit -ni

[hannesm]

A year later, could opam 2.2 be used by default? Or is the "do some ln -f" still the suggested modus operandi?

[tmcgilchrist]

Doing sudo ln -f /usr/bin/opam-2.2 /usr/bin/opam && opam init --reinit -ni still works and most of our services are doing that.
I see less value in keeping opam 2.0 and even 2.1 around now that 2.2 supports all the platforms we need. I don't think anyone is deliberately using earlier opam versions. @shonfeder

[shonfeder]

I see less value in keeping opam 2.0 and even 2.1 around now that 2.2 supports all the platforms we need.

afaiu, the current thinking here is to keep opam versions in the containers so long as they are being shipped by widely used distros that still have LTS.

Currently Debian bullseye ships opam 2.0, iiuc. ELO LTS for bullseye is 2026-08-31.

I mean this to report the current practice as I understand it, not argue for a position.

could opam 2.2 be used by default? Or is the "do some ln -f" still the suggested modus operandi?

I don't recall the thinking on the current default. @mtelvers, could you speak to whether we can/should update the default?