ocaml
depext should track facts, aka .so .a .pkg dependency
from https://github.com/ocaml/opam-repository/pull/11058#issuecomment-352551595
What OCaml software author knows as a fact (by looking at his Makefile for tool names or -l flags to compiler, etc) - is that he needs some binary name in PATH or library name in ld path or pkg-config package etc present on system. I imagine that this specific information should be put in opam file, and not incomplete hardcoded collection of package names (based on assumptions when there are multiple choices) maintained separately from distributions. Then depext tool will have a specialized implementation for each system/distribution that matches those filenames to system package names (e.g. using apt-file on debian) and verifies that all requirements are satisfied or asks user to satisfy in their preferred way. This depext can use hardcoded list of package names too in case there is no tooling available on the system to do the mapping in automated way, but it needs something to start from - e.g. library name used for linking etc, which is not stored in opam files currently. This mapping can be computed on demand (during update) if it is too costly to do at install time. I feel this will lead to a more robust system in the end because it is based on facts, vs current depext specifications which are assumptions.
Hmm, thanks for the feedback, that would indeed be useful.
Loosely related, but for the other side of handling depexts (detecting changes on them to trigger reinstalls, rather than installing them in the first place), there is a way in opam2 that is closer to what you ask for. It's used to detect when a system compiler changes. The bridge from required .so / .pkg file to system packages (which, if not a fact, is what he user can act on) doesn't seem so easy to do in general though. There might be existing tools for this ? E.g. apt-file isn't part of the default debian installation.
As I see it, the dependency looks like this:
① opam package → ② library (.so) → ③ system package
What we do now is hardcode the long link between ① and ③, and leave ② invisible. Finding ② from ① is apparently the easy part, then we have until now relied on crowd efforts to link to ③. It would indeed be nice if it could be automated.
Also, for detecting system installations (rather than acting on them), using ② would probably be much less work than implementing polling for all existing packaging systems out there (probably, because we still need to handle pkg-config, ld.conf, a bunch of system variables, etc., which may be difficult to do reliably). In any case, this seems easier and more reliable to detect changes in system libraries (to trigger reinstallations) than checking the set of installed packages as proposed here.
There might be chicken-egg problem here - there will be no tooling unless there is ①-② info stored in opam file, and vice versa. Of course for the first step could keep crowd-sourced solution for ②-③ mapping.
IMHO @ygrek feature request is very sensible -- the opam package author knows best what (header / shared library) they need -- and that's what should be specified in the opam file. some other tool (i.e. depext) should bridge between the required file(s) and the actual package manager. Surely, depext will need to know on the concrete system where to look for headers and shared objects.
It's too late for 2.0.0, but my suggestion would be to design a format and start adding the info as a x-* field (that will be ignored by opam 2.0.0). It could then be leveraged by new tools, and eventually rewritten to a first-class field for a later release.