Niko Tyni writes: > It's not obvious to me what the ideal setup here should be, when there > are no other reasons for such a dependency than 'need an implementation > of the language the library is written in'.
I think there can be another reason: "needs a minimum version of the interpreter language". (An "if X, then at least version X-Y of X" dependency that also comes up in other contexts, e.g. systemd units and the minimum version to support a given set of directives in them. Debian sometimes tries to express that with `Breaks: X (<< Y~)`.) > On the one hand, the library is probably not useful without an > interpreter for the language, but on the other hand people explicitly > installing the library (as opposed to an application pulling it in) > presumably know what they are going to use it with. But one doesn't always need to use the `/usr/bin/${lang}` interpreter, but could also use an embedded interpreter in another program (usually loaded as a shared library). For example, the pl{perl,python,...} extensions for Postgres. Though these corner cases might not be worth taking too much consideration: installing the interpreter only takes up a bit more disk space. > - the Python Policy [1] says modules must depend on the default Python > runtime package: Depends: python3 (>= 3.Y). I suppose this is needed > at least for the standard library. The dependency scheme seems to be > pretty consistent in the archive. As far as I know Python also byte-compiles modules in postinst, so such a dependency might be required for that alone. Though that tests if the `py3compile` program (or similar) is actually installed. Ansgar