Re: libraries depending on interpreters

[Helmut Grohne <helmut@subdivi.de>]

Hi Niko,

On Sun, Nov 17, 2019 at 04:39:46PM +0200, Niko Tyni wrote:
> at the last tech-ctte meeting the question came up of whether there's
> a general rule in Debian about libraries/modules depending (or not)
> on the corresponding interpreters for their implementation language.

You've already mentioned that most ecosystems (but java) tend to have
such a dependency in practice. Ecosystems not mentioned thus far:

 * lua is inconclusive. Some lua modules have a dependency, most
   don't. Though lua is often embedded, so not having the dependency
   kinda is relevant.

 * Although not interpreted, go is quite similar as it practically ships
   sources. go tends to lack compiler dependencies.

 * As far as I can see R tends to have a dependency on r-base-core.

 * Also consider that C libraries (even -dev packages) tend to not
   depend on gcc.

Another aspect that hasn't been considered much yet is multiarch. This
is where things become hairy due to our lovely multiarch interpreter
problem.

In a perfect world, we'd want language modules (and extensions) to be
coinstallable for multiple architectures such that you can use say an
amd64 Python interpreter executable and an i386 embedded Python
interpreter in the same installation. Among other things, an interpreter
dependency prevents us from doing so (unless annotated :any). So the
perfect multiarch world would be in favour of not having such
interpreter dependencies. This is a bit hypothetical though. Even
installing a foreign Python is next to practically impossible.

Hope this helps

Helmut