Open avsm opened 7 years ago
(I appreciate an explicit broken:
marker, and used available: [ ocaml-version = "0" ]
to mark packages uninstallable (e.g. some mirage-net-xen versions which have security issues, https://github.com/ocaml/opam-repository/blob/master/packages/mirage-net-xen/mirage-net-xen.1.1.1/opam#L18 -- this works fine with earlier opam (at least 1.2))
available: false
would have worked too :)
Or even available: broken
, abusing the handling of undefined variables... That way you would get:
Your request can't be satisfied:
- unmet availability conditions: broken
Even available: !(broken-needs-newer-clang & os = "darwin")
would work.
DISCLAIMER: I am not advising the above, just saying that it's possible. And the main point here is easier triaging and automated handling, which this hack would clearly not help with. A broken:
field seems a good idea.
Discussed with @altgr the possibility of repository triagers marking a package as broken, with a reason and a constraint. e..g
broken : "needs newer clang" {os = "darwin"}
CI can use this to triage and move on - right now we need to block on doing a fix which is sometimes difficult on the spot and/or simply not possible (if a depext is missing).
I could imagine something around:
This would help us design a workflow for making it easier for external contributors to give us fixes for problems, and also for CI to semi-automatically mark packages as known-broken. The CI could also verify that broken packages are in fact still broken.