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