Why is opam trying to upgrade dune?

In attempting to install a package with no dependencies (bitlib)
I am confronted with opam ordaining that dune be upgraded and the entire stock of installed packages be recompiled as a result.
this is highly undesirable on my system which crashes regularly when multiple cores are used and which -j 1 does not entirely eliminate.

↘ downgrade jbuilder transition to 1.0+beta20.2
↗ upgrade dune 1.9.3 to 2.1.3
∗ install dune-private-libs 2.1.3 [required by dune-configurator]

does anyone know what is causing this or how to query opam to find out?

Hi! Sorry we didn’t get you an answer sooner :frowning:

I imagine opam is trying to upgrade dune just because there’s a newer version out. You can prevent this by pinning to a specific version.

iiuc, An upgrade to dune requires rebuilding all the libraries that build with it because, unfortunately, opam doesn’t currently offer a satisfactory of specifying dune as a build-only dependency. (See https://github.com/ocaml/opam-repository/issues/14185 for background).

You might try enabling caching on dune to speed up the builds: https://dune.readthedocs.io/en/stable/caching.html#caching

thanks for the feedback.
it didn’t work, it still comes back with a request to recompile everything installed.
I cannot remember which packages I nurse-maided into installation by altering their opam file to limit parallelism but with over fifty I don’t wish to find out again!

isn’t it odd that it insists on recompiling even though the pin is at the installed version number?
it did eliminate this line:
downgrade jbuilder transition to 1.0+beta20.2

It sounds unlikely to be the case that dune is upgraded whenever there is a new release.
hasn’t happened to me before.

with debug:

00:00.988  STATE                  Detected changed packages (marked for reinstall): { 
... <list of packages> }
00:01.008  STATE                  Switch state loaded in 0.421s
00:01.010  FILE(switch-state)     Wrote /home/dev/.opam/default/.opam-switch/backup/state-20200220093608.export in 0.001s
[NOTE] Pinning unchanged
00:01.023  FILE(switch-state)     Wrote /home/dev/.opam/default/.opam-switch/switch-state in 0.002s
00:01.044  FILE(environment)      Wrote /home/dev/.opam/default/.opam-switch/environment in 0.001s
dune is now pinned to version 1.9.3

00:01.044  CLIENT                 UPGRADE dune
00:02.409  SYSTEM                 [log-4742-4bcc67] (in 0.258s) lsb_release -s -r
00:02.439  GSTATE                 Failed to evaluate global variable sys-ocaml-version: "ocamlc": command not found.
00:03.211  CLIENT                 Orphans: (changes: { dune.1.9.3 }, transitive: false) -> full {}, versions {}
00:04.667  SOLVER                 resolve request=install:() remove:() upgrade:(dune)

You have some package that are marked for reinstall. You can try opam reinstall --list-pending to list them, and if the package you don’t want to rebuild is listed, use opam reinstall --forget-pending to drop the entire list.


if the opam file has changed, or a dependency need rebuild, it can happen, yes. Pinning to version ensure that you keep the same version, not forbid rebuilding. It sufficient/resolves the problem for most cases but seems that here no :slight_smile:

1 Like

no luck with --forget-pending but dune-configurator appeared again so I tried

opam install dune-configurator

to see what would happen and a bunch of recompiles were given:

The following actions will be performed:
  — install   dune-configurator          1.0.0
  » recompile pcre                       7.4.1   [uses dune-configurator]

however, the opam packages database pcre is not listed with a dependency on
additionally, there are several packages in the recompile list that DO depend on it
but of course they are already installed while dune-configurator is NOT already installed,
at least not as given by [opam list].
so I wonder whether something has happened to corrupt the opam database.

That version of pcre has dune-configurator as a direct dependency.
You can see the list of packages that depends on dune-configurator with opam list --depends-on dune-configurator.
What happened here, is that dune-configurator was added to package without updating their version, it’s from there that the rebuild happen without version upgrade.
If you really don’t want to rebuild everything because you want to test something, you can still clone the opam-repository locally, revert that commit, add it as the primary repository in your switch and update it. Not that it can lead to inconsistencies.