-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
opam admin check
#11378
Comments
Rectification: cycles don't mean the packages are not installable: there might be a cycle between two specific versions |
Edited the OP with an update that removes conflicting packages from the cycles. Cycles are still problems that could manifest on the user side, so the proper fix, if the packages are actually installable, is to mark them as conflicts. |
Should help with issues ocaml#3213, ocaml/opam-repository#11365 See ocaml/opam-repository#11378 for some preliminary results.
Update: with the fixed dependency of
These are real issues, that would have been tricky to find otherwise. For example, assuming you have
This is due to the test dependencies of |
follow-up from ocaml#11378. If nobody can install them, no point in keeping them in the repo!
follow-up from ocaml#11378. If nobody can install them, no point in keeping them in the repo
@AltGr is this command in opam-2.0.x or will it be in 2.1? @kit-ty-kate is working on an integration of https://github.com/ocurrent/ocaml-ci to replace the current datakit-ci, and so we could integrate this as a scheduled cron task on the master branch. |
This issue has been open 90 days with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. If you come across this issue in the future, you may also find it helpful to visit our forum at https://discuss.ocaml.org where queries related to OCaml package management are very welcome. |
I am not entirely sure which action should be taken on this issue, or whether it should be closed. I agree that the current based opam-repo-ci could do more: an uninstallability check, and also a cycle check. But I'm not sure whether this should be tracked in the opam-repository as an issue here. Any opinions? |
i believe those are tracked by ocurrent/opam-repo-ci#118 and ocurrent/opam-repo-ci#69 so it's probably fine to close this ticket |
Closing, if there's still something to keep this open please don't hesitate to comment and reopen. |
is an in-progress new command for analysing the repo. Nothing as in-depth as the unfortunately unmaintained "weather service", but we have been hitting problems with dependency cycles recently (ocaml/opam#3213, #11365 ), and those at least are fairly easy to check for.
So here are some preliminary reports for the pleasure of our dear repository maintainer team 😸
Uninstallable packages
These 46 packages were detected as uninstallable (due to missing or conflicting dependencies). They should be fixed, or have no reason to remain in the repository:
These are dependent on the above, so they are also broken:
Additionally, these are uninstallable when
--with-test
and--with-doc
are turned on. Their corresponding dependencies need to be fixed:And their dependents:
The tool doesn't include explanations for uninstallability at the moment, but just
opam install [--with-test] [--with-doc] <uninstallable-package>
should give you fairly good explanations.Dependency cycles
Strong component analysis of the dependency graph provides the following cycles. This doesn't necessarily make the packages uninstallable individually, but can actually lead to worse results, because the solver doesn't detect it, and can return a solution that is then rejected by opam; also note that depopts can lead to cycles, while they don't affect the installability check above:
Which amounts to the following broken packages:
If we add in
test
/doc
dependencies, the situation is much worse currently, as has been noticed already (#11365):Which amounts to the following 669 broken packages :
EDIT: fixed (wrong) mentions of cycles leading necessarily to broken packages, and reduced cycles by taking conflicts into account
The text was updated successfully, but these errors were encountered: