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
