downgrading after changing OS constraints

[avsm]

The latest Core 109.15.00 is broken on non-Linux (see janestreet/core#12). I added an os: ["linux"] constraint in my local opam repository, but this triggered a brute force search that would downgrade all my packages to some non-optimal versions.

However, manually removing type_conv no longer works:

$ opam remove type_conv
The dependency core.109.15.00 of package async_core.109.15.00 is not available for your compiler or your OS.
'opam remove type_conv' failed.

So I have no choice but to upgrade. Notice the non-optimal solution below where other packages go straight to the lowest versions instead of the high:

 - downgrade yojson.1.1.3 to 1.0.3 [required by github]
 - downgrade typerex.1.99.4-beta to 1.99.0-beta
 - downgrade react.0.9.4 to 0.9.3 [required by eliom, github, shared-memory-ring]
 - downgrade re.1.2.0 to 1.0 [required by cow, github]
 - downgrade type_conv.109.15.00 to 109.14.00 [required by core_extended, cow, custom_printf, github, shared-memory-ring]
 - downgrade mirari.0.9.1 to 0.9.0
 - downgrade pipebang.109.15.00 to 109.14.00 [required by core_extended, github, shared-memory-ring]
 - downgrade ocp-indent.1.1.0 to 0.1.0
 - downgrade xmlm.1.1.1 to 1.1.0
 - downgrade herelib.109.15.00 to 109.14.00 [required by core_extended, github, shared-memory-ring]
 - recompile atdgen.1.2.2 [use yojson]
 - downgrade ocp-build.1.99.4-beta to 1.99-beta
 - downgrade lwt.2.4.3 to 2.4.1 [required by eliom, github, shared-memory-ring]
 - recompile zed.1.2 [use react]
 - recompile uri.1.3.6 [use re]
 - downgrade bin_prot.109.15.00 to 109.14.00 [required by core_extended, github, shared-memory-ring]
 - downgrade comparelib.109.15.00 to 109.14.00 [required by core_extended, github, shared-memory-ring]
 - recompile dyntype.0.9.0 [use type_conv]
 - downgrade fieldslib.109.15.00 to 109.14.00 [required by core_extended, github, shared-memory-ring]
 - recompile ocaml-data-notation.0.0.10 [use type_conv]
 - downgrade pa_ounit.109.15.00 to 109.14.00 [required by core_extended, custom_printf, github, shared-memory-ring]
 - downgrade sexplib.109.15.00 to 109.14.00 [required by core_extended, custom_printf, github, shared-memory-ring]
 - downgrade variantslib.109.15.00 to 109.14.00 [required by core_extended, github, shared-memory-ring]
 - recompile wget.0.1.0 [use typerex]
 - recompile js_of_ocaml.1.3.2 [use react]
 - recompile ocsigenserver.2.2.0 [use react]
 - downgrade lambda-term.1.4 to 1.2 [required by github]
 - downgrade cow.0.5.3 to 0.4.0
 - recompile oasis-mirage.0.3.0a [use type_conv]
 - downgrade custom_printf.109.15.00 to 109.14.00
 - install core.109.14.01 [required by core_extended, github, shared-memory-ring]
 - downgrade eliom.3.0.3 to 3.0.1
 - recompile utop.1.4.0 [use react]
 - install async_core.109.14.00 [required by github, shared-memory-ring]
 - install core_extended.109.14.00
 - install async_unix.109.14.00 [required by github, shared-memory-ring]
 - install async_extra.109.14.00 [required by github, shared-memory-ring]
 - install async.109.14.00 [required by github, shared-memory-ring]
 - recompile cstruct.0.7.1 [use herelib, pipebang, react, type_conv]
 - downgrade shared-memory-ring.0.3.1 to 0.2.0
 - recompile xenstore.1.2.1 [use herelib, pipebang, react, type_conv]
 - downgrade mirage.0.8.1 to 0.6.0 [required by github]
 - downgrade mirage-net.0.5.2 to 0.3.0 [required by github]
 - downgrade cohttp.0.9.6 to 0.9.4 [required by github]
 - downgrade github.0.4.3 to 0.4.1

[smondet]

We had the same problem with Core 109.15, and we tried many combinations of opam install <thing>.<version> and opam pin <thing> <version>. Especially with <thing> = core and <version> = 109.14.01.

And we also ended up triggering "brute force" errors and wrong downgrades (so it's a more general problem than os: [ "linux"]).

BTW, my solution was more aggressive :)

rm -fr packages/*.109.15.* 

(https://github.com/smondet/opam-repository/commit/6775e7e5a44f9e7fe93a5ae5fe4053cf47e82e12)

[avsm]

Another observation is that a subsequent upgrade after the "mass downgrade" due to the brute force solver works pretty well:

$ opam upgrade
. brute-force exploration timed-out [931 states, 5s].
You might need to add explicit version constraints to your request to get a better answer.
The following actions will be performed:
 - install core.109.14.01 [required by async, core_extended]
 - downgrade typerex.1.99.4-beta to 1.99.0-beta
 - upgrade lwt.2.4.1 to 2.4.3 [required by eliom, utop]
 - downgrade re.1.2.0 to 1.0 [required by cow, uri]
 - install async_core.109.14.00 [required by async]
 - install core_extended.109.14.00
 - downgrade ocp-build.1.99.4-beta to 1.99-beta
 - downgrade js_of_ocaml.1.3.2 to 1.2 [required by eliom]
 - upgrade lambda-term.1.2 to 1.4 [required by utop]
 - recompile ocsigenserver.2.2.0 [use lwt]
 - downgrade cow.0.5.3 to 0.4.0
 - downgrade uri.1.3.6 to 1.3.0
 - install async_unix.109.14.00 [required by async]
 - recompile wget.0.1.0 [use typerex]
 - downgrade utop.1.4.0 to 1.2.1
 - downgrade eliom.3.0.1 to 2.2.2
 - install async_extra.109.14.00 [required by async]
 - install async.109.14.00
6 to install | 2 to reinstall | 2 to upgrade | 8 to downgrade | 0 to remove

Does it make sense to run the solution calculated for an upgrade through another upgrade? It should always end up with a fixed point solution right?

[samoht]

I have a patch in my local branch who should fix this, but I don't know what's the best way to test it before releasing it in the wild ...

[samoht]

Could you please try with the latest version of OPAM to see if this issue is solved ?

[avsm]

I'll revert my opam repository to the broken one later this evening and try this out.

On 29 Mar 2013, at 15:31, Thomas Gazagnaire notifications@github.com wrote:

Could you please try with the latest version of OPAM to see if this issue is solved ?

— Reply to this email directly or view it on GitHub.