Bug#908203: opam: Should not depend on aspcud any more
Hi all,
To update on this issue, I believe there is a solution we can agree on, and would hopefully not be too difficult to put in place :
- In the ocaml-mccs source [1], you can toggle dynamic linking to a system installation of GLPK copying src/glpk/dune-shared over to src/glpk/dune
- It may then be packaged independently with that change. ocaml-mccs itself is a fork that has much diverged from the original MCCS [2] project, so would that be OK ?
- We will be releasing a 2.0.5 patch release shortly, and having this issue solved would be lovely. I'd be happy to help with any build issues in the process.
[1] https://github.com/AltGr/ocaml-mccs
[2] http://www.i3s.unice.fr/~cpjm/misc/mccs.html
> - Louis Gesbert, 26/02/2019 16:15 -
> Hi all,
>
> Thanks a lot for the packaging efforts. It's not much tested in the wild anymore, as Anil pointed out, but aspcud is still part of our test-suite and _should_ work.
>
> The error you are getting is internal to aspcud, though (it happens between gringo and aspcud itself), so that might point us to a discrepancy of versions between aspcud/gringo/clasp, which already happened in the past. I was unable to reproduce yet using the stable packages (clasp 3.2.1-3, gringo 5.1.0-4, aspcud 1:1.9.1-2+b1) and opam master (which shouldn't change much). It would be worth ① checking the tool versions, ② extracting the Cudf file sent to the solver (set OPAMCUDFFILE=/tmp/foo), ③ checking the aspcud debug output (by running it directly on the generated file).
>
> I understand that getting ocaml-mccs into Debian might not be easy. The mccs version included has been so widely changed from the original (which is unmaintained) that I would argue it is acceptable to include it besides the original, maybe with a different name (the current one would suggest a binding); but we do also include a stripped version of GLPK in the source. That on the other hand is unpatched, and there are linking options to rely on an external version (either statically or dynamically). I am willing to give a hand if anyone feels like attempting to package it.
>
> FWIW, we are also working on a Z3 backend, which doesn't require new or specific bindings. For that one, Debian packaging while relying on `libz3-ocaml-dev` would probably be easier than the source distribution.
>
> Best,
> Louis
>
>
> > - Anil Madhavapeddy, 25/02/2019 19:16 -
> > On Sun, 9 Sep 2018 10:44:14 +0200 Ralf Jung <post@ralfj.de> wrote:
> > > Hi Mehdi,
> > >
> > > > On 2018-09-07 12:42, Ralf Jung wrote:
> > > >> Package: opam
> > > >> Version: 2.0.0-2
> > > >> Severity: normal
> > > >>
> > > >> Dear Maintainer,
> > > >>
> > > >> Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html:
> > > >>
> > > >>> As of 2.0.0, opam comes with a CUDF solver built-in by default, so unless you
> > > >>> have specifically compiled without it, you shouldn't have to be worried about
> > > >>> installing an external solver.
> > > >>
> > > >> So, aspcud should at best be a recommendation, not a dependency. Likely, it
> > > >> should just be a suggestions; the internal solver is used by default even when
> > > >> aspcud is installed.
> > > >>
> > > >
> > > > If I am not mistaken, the built-in solver is not enabled in the Debian package
> > > > because we are missing ocaml-mccs to make it work. So, for now, the dependency
> > > > is still needed.
> > >
> > > Oh... that's a bummer, because using the new built-in solver is one of the
> > > biggest reasons to update to opam 2 for me. :/ aspcud keeps computing really
> > > strange solutions in some cases I frequently run into.
> > >
> >
> > Dear Debian opam maintainers,
> >
> > It's really great to see opam 2.0.3 in Debian testing now! I just wanted
> > to highlight the importance of using the builtin mccs solver in order
> > to get a working opam installation on Debian Buster however.
> >
> > Right now, the opam repository seems to fail badly when using the
> > aspcud solver out of the box:
> >
> > """
> > $ docker run -it debian:testing
> > # apt update
> > # apt install -y opam
> > # opam init -ya
> > [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
> >
> > 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-4710/solver-in-4710-548b09 /tmp/opam-xxx-4710/solver-out-4710-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 CCed Louis Gesbert in case he can shed any light on how to
> > make aspcud work more reliably, but I strongly suspect that we've
> > been testing the builtin mccs for so long that it's become the only
> > solver in the opam 2.0.x branch capable of actually working with
> > the current opam-repository.
> >
> > regards,
> > Anil
> >
>
Reply to: