I am using opam 2.1.2, in a switch with OCaml 4.08.1, and I’d like to install a single package (apron, but it happens with any package, in fact). However, if I try opam install apron, for some reason, it decided that it needs to recompile all of my packages:
The following actions will be performed:
↻ recompile ocaml-base-compiler 4.08.1 [upstream or system changes]
↻ recompile ocaml-config 1 [uses ocaml-base-compiler]
↻ recompile ocaml 4.08.1 [uses ocaml-base-compiler]
↻ recompile seq base [uses ocaml]
↻ recompile opam-file-format 2.0.0 [uses ocaml]
...
Sometimes I cannot afford to spend the time to do it (especially because that means I need to recompile all of my software that depends on the switch), so I’d like to know: is there a way to tell opam not to update the base compiler?
If possible, I’d also like to understand which updates were made that require opam to reinstall the base compiler, but without changing the version number. I don’t recall seeing that before.
(By the way, if there is a way to force the installation of a single package, or if there is definitively no way to do so, in either case it would be nice to provide a more informed answer to the related StackOverflow question.)
The official opam repository has a policy of publishing packages with the exact same version as the underlying software. What this means is that if an opam file has to be updated while the underlying software stays at the same version, you get an update without a change of version, and that’s usually very confusing.
In this particular case, glibc 2.34 introduced changes that broke the build of the compiler. The compiler was fixed in 4.13 to work around that, but eventually it was decided to also apply the patch to all versions of the compiler available on opam, without making new releases of the compiler.
I don’t think you’ll be able to skip the big recompilation. You could, in theory, change the opam repository for your switch to point to an older commit (before the addition of the patch), but that’s not recommended, and I’m not sure what the exact commands would be.
Both are very useful and interesting replies, thanks a lot! (I’d like to accept both as “solutions”, but unfortunately I can only choose one)
Indeed, I updated my glibc not long ago, so that explains the need to update. As long as it’s not just related to me having done some “messing up” of my repository, it’s fine for me. I wanted to avoid unknowingly doing things to my switch that might lead me to having that issue again and again for no good reason.
I’ll also keep in mind the opam pin --current option for later, I’m sure it will be useful in the future!
It’s not so much policy, as unfortunate reality at the moment! In most cases, packages which are updated usually get a version suffix -1 added, and it’s unusual for packages outside the compiler to be allowed to carry release patches in opam-repository. The problem with the suffix is that lock files (and commands which specify the exact version) will still pick up the old package. There is a proposal to solve this in future without needing to change the version number (see proposal in opam’s wiki) which would make the revision of the package clear.
We do also keep back-ports such as this to an absolute minimum - for the OCaml compiler packages, it’s strictly limited to patches that allow old OCaml versions to be compiled with newer C compilers (the previous back-ported related to -fvisibility changes in GCC, for example).