debian testing/ubuntu disco opam packages result in solver failure on init

[avsm]

The Debian testing and Ubuntu Disco packages are both packaged in such a way that they use a different set of solver packages than those published by upstream opam.

The Debian bug report about this packaging is #908203, but there's a risk that this won't get fixed due to the Debian freeze. Filing this bug here so we can track it, as obviously a large number of our users are on Debian and Ubuntu.

The behaviour can be reproduced by docker run ubuntu:disco sh -c "apt-get update && apt-get -y install opam && opam init -ya":

root@ad2126840da4:/# opam init
[WARNING] Running as root is not recommended
[NOTE] Will configure from built-in defaults.
Checking for available remotes: rsync and local, git, mercurial, darcs. Perfect!

<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
[default] Initialised

<><> Required setup - please read <><><><><><><><><><><><><><><><><><><><><><><>

  In normal operation, opam only alters files within ~/.opam.

  However, to best integrate with your system, some environment variables
  should be set. If you allow it to, this initialisation step will update
  your bash configuration by adding the following line to ~/.profile:

    test -r /root/.opam/opam-init/init.sh && . /root/.opam/opam-init/init.sh > /dev/null 2> /dev/null || true

  Otherwise, every time you want to access your opam installation, you will
  need to run:

    eval $(opam env)

  You can always re-run this setup with 'opam init' later.

Do you want opam to modify ~/.profile? [N/y/f]
(default is 'no', use 'f' to choose a different file) y   
A hook can be added to opam's init scripts to ensure that the shell remains in sync with the opam environment when they are loaded. Set that up? [y/N] y

User configuration:
  ~/.profile is already up-to-date.
[NOTE] Make sure that ~/.profile is well sourced in your ~/.bashrc.


<><> Creating initial switch (ocaml-system>=4.02.3) <><><><><><><><><><><><><><>

[ERROR] Solver failed: "/usr/bin/aspcud /tmp/opam-xxx-6240/solver-in-6240-548b09 /tmp/opam-xxx-6240/solver-out-6240-8b8a2d
        -count(removed),-sum(request,version-lag),-count(down),-sum(solution,version-lag),-count(changed)" exited with code 1 "ERROR: grounder returned with
        non-zero exit status"
Switch initialisation failed: clean up? ('n' will leave the switch partially installed) [Y/n] 

CCing @glondu to see if we can help with the upstream packaging

[ghost]

Shouldn't this be an opam issue?

[avsm]

@diml - it is; i transferred it yesterday after submitting it in the wrong browser tab :-)

[ghost]

Ah ok :) I was going through my dune mail notifications

[avsm]

Ubuntu 19.04 has just been released and still has the bug

<><> Creating initial switch (ocaml-system>=4.02.3) <><><><><><><><><><><><><><>
[ERROR] Solver failed: "/usr/bin/aspcud /tmp/opam-xxx-4699/solver-in-4699-548b09 /tmp/opam-xxx-4699/solver-out-4699-8b8a2d
        -count(removed),-sum(request,version-lag),-count(down),-sum(solution,version-lag),-count(changed)" exited with code 1 "ERROR:
        grounder returned with non-zero exit status

I've reported it on Launchpad as well in case it can benefit from a backport: https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1825394

[AltGr]

@avsm thanks for tracking this. It's unfortunate that Debian doesn't compile with the built-in solver, and at the same time has a broken install of aspcud :/

[jasonperry]

In case anyone gets bitten by this like I did and stumbles across this page, a workaround using the distro's opam package is to apt install mccs , then opam init --solver=mccs .

[Siltaar]

Released Debian stable Buster is affected also.
The workaround solves the issue after a :

rm -rf ~/.opam

[mato]

I've run into this issue again this week while working on Debian packaging for jackline (hannesm/jackline#208). In its current state, opam is essentially unusable in Debian stable.

While Debian bug #908203 fixes this in unstable, I'd like to work with the maintainers (upstream and Debian) to find a suitable fix for stable. I can see two possible solutions:

1. Declare that opam in stable is broken, and replace it with the fixed opam (2.0.5-1) from unstable. I'm not sure that this is possible given Debian's policy of not updating to newer upstream versions in stable, though I think that an exception would be justified in this case.
2. Patch opam in stable to:
   a. Add mccs (the external mccs solver) to Depends:.
   b. Force the default solver to be mccs (if not otherwise specified by the user).

Thoughts? I don't know the Github IDs of the Debian maintainers of opam, could someone who does please ping them to bring this issue to their attention? Once we have agreement on a way forward then I can file a new bug with Debian.

[glondu]

While not being the Debian maintainer of opam per se, I am a member of the Debian OCaml Team and can help on this issue.

Your alternative 1 is not possible. If we declare that opam is broken in stable, I think it can be removed from stable. Wouldn't it be better than having a non-working package? I need other opinions... In parallel, a backport can be done, so that the user experience (apt install opam on stable) is the same with the exception of having to add a line in /etc/apt/sources.list.

As for your alternative 2, it looks doable if the patch is not too intrusive.

[dra27]

IIRC if the ocaml-mccs package from unstable is backported (which doesn't use GLPK) then it's merely necessary to rebuild the opam package in stable - there's nothing else which needs backporting

[mato]

IIRC if the ocaml-mccs package from unstable is backported (which doesn't use GLPK) then it's merely necessary to rebuild the opam package in stable - there's nothing else which needs backporting

Yes, but that is not a fix that will un-break the existing opam package in stable, since there's no way to add (per Debian policy) new packages to stable. Also, if a backport is done, then it may as well be based off the opam package in unstable, which, AFAICT, uses a built-in mccs and thus does not require backporting ocaml-mccs at all.

[glondu]

it may as well be based off the opam package in unstable, which, AFAICT, uses a built-in mccs and thus does not require backporting ocaml-mccs at all

Are you sure of that? The Debian package build-depends explicitly on ocaml-mccs...

[mato]

Are you sure of that? The Debian package build-depends explicitly on ocaml-mccs...

Indeed, you're right. It's there as libmccs-ocaml-dev. So that would also require backporting. In any case, if a backport is done, it may as well be done using the version in unstable, I don't see any difference in effort.

I'll take a look at what I can do regarding alternative (2) for stable.

[mato]

@glondu I have a possible solution for alternative (2) / a fix for opam in stable. Posting all of it here as it's surprisingly simple.

The following changes need to be applied to debian/control:

--- debian/control.orig	2020-02-17 11:05:57.633804804 +0000
+++ debian/control	2020-02-17 10:40:19.364233872 +0000
@@ -22,7 +22,7 @@
  libopam-file-format-ocaml-dev,
  libjsonm-ocaml-dev,
  libopam-file-format-ocaml-dev,
- aspcud,
+ mccs,
  rsync,
  unzip,
  openssl,
@@ -50,7 +50,7 @@
  ${misc:Depends},
  opam-doc (= ${source:Version}),
  build-essential,
- aspcud | mccs | packup,
+ mccs,
  opam-installer,
  bubblewrap [linux-any],
  unzip,

and the following patch needs to be added to debian/patches:

diff --git a/src/solver/opamCudfSolver.ml b/src/solver/opamCudfSolver.ml
index 03486f16..b3b8aa6f 100644
--- a/src/solver/opamCudfSolver.ml
+++ b/src/solver/opamCudfSolver.ml
@@ -215,8 +215,8 @@ let make_custom_solver name args criteria =
 
 let default_solver_selection =
   OpamBuiltinMccs.all_backends @ [
-    (module Aspcud: S);
     (module Mccs: S);
+    (module Aspcud: S);
     (module Aspcud_old: S);
     (module Packup: S);
   ]

The former removes aspcud from Build-Depends: and both aspcud and packup from Depends:. The resulting package will therefore depend only on mccs. The latter changes the external solver logic to always prefer mccs over aspcud.

I've tested this by building a binary package and then running various combinations of opam init, followed by opam switch create 4.09.0 in Docker containers, and the result works as intended. I also double-checked that mccs is used even in the presence of an aspcud package.

The only minor complication I can see is when upgrading existing systems: if a user has done apt install opam and for has explicitly specified aspcud or packup as their external solver in .opam/config, then upgrading to this package and running apt-get autoremove (or equivalent) may cause such a configuration to break due to the external solver(s) being removed. However, IMHO the chances of such configurations existing in the wild are zero, and this could be addressed with a changelog entry that will get reported at package installation time.

What do you think? Would this solution be acceptable to stable?

[rjbou]

It uses then mccs as an external solver, good point!

For the breaking case you describe, I suppose that, if a user specified explicitly aspcud, if apt tries to remove it, it will be noticed & act on purpose —we could add a changes message?. I think that we can reasonably rely on that. Better have a most case opam working than minor cases not working.

ping @mehdid @nbraud (debian maintainers) & @AltGr

[mato]

For the breaking case you describe, I suppose that, if a user specified explicitly aspcud, if apt tries to remove it, it will be noticed & act on purpose —we could add a changes message?

Yes, that's what I had in mind. As I wrote, I very much doubt there are any cases in the wild where people are using the DEB and have specified aspcud, since it doesn't work anyway.

[glondu]

I've sent a recap message to the Debian bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908203#68

[whoek]

With Debian GNU/Linux 10 (buster)
I am still getting the same error as issue posted, even after running following :.

rm -rf ~/.opam
apt install mccs
opam init --solver=mccs

It created the initial switch ok, which is: ocaml-system.4.05.0
However, when trying to install another version -- I get same error as above

opam switch install 4.10.0

Get this error (same as above)

[ERROR] Solver failed: "/usr/bin/aspcud /xxx/.opam/log/solver-in-27189-5f1023 /xxx/.opam/log/solver-out-27189-58c514
        -count(removed),-sum(request,version-lag),-count(down),-sum(solution,version-lag),-count(changed)" exited with code 1 "ERROR: grounder
        returned with non-zero exit status"

Any suggested workaround?

[mato]

@whoek This is with the stock Debian opam? Try dpkg --remove aspcud.

[rjbou]

@whoek
When you initialised opam, you gave the option --solver, so opam used it to create the default switch, but this option is a common option for all commands, not used by init to configure your opam. That's why when you tried an install afterwards, it used aspcud, which is still the default on debian package.
You can use the OPAMSOLVER environment variable, or add an opamrc with the solver fields .

[whoek]

@rjbou - Make sense. Many Thanks for reply.
Now working,using:

rm -rf ~/.opam
apt install mccs
opam init --solver=mccs
opam switch create 4.10.0 --solver=mccs

[glondu]

Opam should work out of the box with mccs now, with Debian 10.4.

[rjbou]

Hourray! Thanks all!