Open AltGr opened 6 years ago
AltGr
commented
6 years ago Rectification: cycles don't mean the packages are not installable: there might be a cycle between two specific versions a.va and b.vb, which wouldn't be co-installable, but a.va may be installable with other versions of b, and conversely.
AltGr
commented
6 years ago 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.
AltGr
commented
6 years ago Update: with the fixed dependency of jbuilder, an enumeration of cycles becomes possible:
* io-page = 1.0.0 → mirage-types (>= 1.1.0 & < 3.0.0)
* core_kernel (>= 112.01.00 & < 113.24.00) → pa_test (< 109.45.00 | >= 109.53.00 & < 111.08.00)
* expect = 0.0.2 → oasis = 0.2.0* io-page = 1.0.0 → mirage-types (>= 1.1.0 & < 3.0.0)
* js_of_ocaml (>= 2.6 & < 3.0) → base64 >= 2.1.2 → bos → logs = 0.4.2
* logs >= 0.5.0 → js_of_ocaml (>= 2.6 & < 3.0) → base64 >= 2.1.2 → bos
* js_of_ocaml (>= 2.6 & < 3.0) → base64 >= 2.1.2 → bos → mtime
* js_of_ocaml (>= 2.6 & < 3.0) → base64 >= 2.1.2 → bos → logs = 0.4.2
* logs >= 0.5.0 → mtime → js_of_ocaml (>= 2.6 & < 3.0) → base64 >= 2.1.2 → bos
* mtime → js_of_ocaml (>= 2.6 & < 3.0) → base64 >= 2.1.2 → bos
* core_kernel (>= 112.01.00 & < 113.24.00) → pa_test (< 109.45.00 | >= 109.53.00 & < 111.08.00)
* expect = 0.0.2 → oasis = 0.2.0
* oasis = 0.2.0 → expect >= 0.0.4 → batteries (>= 2.5.0 & < 2.7.0) → qtest < 2.2These are real issues, that would have been tricky to find otherwise. For example, assuming you have js_of_ocaml.2.6 already installed, building the tests for base64 would become broken:
% opam reinstall --with-test base64
The actions to process have cyclic dependencies:
- ∗ base64.2.1.2 → ∗ js_of_ocaml.2.6 → ∗ logs.0.6.2 → ∗ bos.0.2.0 → ∗ base64.2.1.2This is due to the test dependencies of base64 transitively including logs, which in turn has an optional dependency on js_of_ocaml... which depends on base64. There is no possible order for opam to build these.
Note that marking the test dependency to bos in package base64 as {post} would fix the build cycle (but as a result, bos would not actually be available during the tests... maybe in opam 2.1)
avsm
commented
4 years ago @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.
github-actions[bot]
commented
4 years ago 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.
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 (https://github.com/ocaml/opam/issues/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-testand--with-docare 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/docdependencies, 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