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

Reply via email to