Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport CUDF trimming to the 2.0 branch #4538

Closed
wants to merge 17 commits into from

Conversation

kit-ty-kate
Copy link
Member

WIP

This appears to give huge solver speedups with MCCS on some tests
It's not what gives the most speedup, and it could be harmful for
maximisation / best-effort requests.
Determines how far we go through the dependencies of the specified packages to
extract conflicts. Defaults to 2, 0 disables conflict detection, more than 5 is
probably meaningless.

Higher values make the preprocessing take around 2s, but that could probably be
optimised.
Computation of dependencies was based on `OpamCudf.Graph.close_and_linearize`,
which is using a topological traversal of the dependency graph. Unfortunately,
when cycles appear (which is now allowed with `post` dependencies, but could
also happen before with malformed opam repos), this can cause dependencies to be
missed.

I believe this could manifest mysteriously in several bugs, but I dug it up on
an issue about `opam remove -a` no longer working, reporting a conflict while
attempting to remove `ocaml-config`.

Note 1: there are small changes in the API for simplicity's sake: the dependency
functions now return sets, and there is a separate sort function. We didn't use
the order anyway and always converted to sets, except in one `opam list` case
where we actually needed only the sort and not the dependency computing.

Note 2: I used a conservative approach (fix the bug first), but it would make
much sense to compute the cone directly from `OpamSolver` without going through
`OpamCudf` and back, which is quite coslty.
- restriction to the cone of mentionned packages was broken
- the command could cause conflicts in the case of orphan packages; when we only
  do removals that won't lead to rebuilds, as is the case with autoremove
  without argument, we can actually just ignore orphans (with argument, only
  keep orphans within the reverse dep cone, as usual).
Instead of removing all unrelated packages, remove just the versions of
related packages that we are guaranteed not to need.
@kit-ty-kate kit-ty-kate changed the base branch from master to 2.0 February 10, 2021 11:53
@rjbou rjbou added the PR: WIP Not for merge at this stage label Feb 10, 2021
@rjbou rjbou added this to the 2.0.9 milestone Feb 10, 2021
@dra27
Copy link
Member

dra27 commented May 5, 2021

Had we reached a conclusion that this won't work and that rebuilding opam 2.0 with GLPK 5 is the best we can do for now?

@dra27 dra27 closed this May 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: WIP Not for merge at this stage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants