Hi, 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.
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'. 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. It would be nice to get some input on this. I've surveyed the archive and packaging policies a bit wrt. this, and I'm listing a few observations below. Please note that I'm not an expert on most of these so I may well have missed some things. Corrections and clarifications are welcome of course. It's probably best to leave compiled (binary) modules out of scope for this, as those will normally require some kind of ABI dependency towards the interpreter anyway. I note that there can be other reasons for a dependency on the interpreter packages. For instance, if the language standard library is not shipped in the same package as the interpreter (like with python3-minimal, perl-base) and the module needs the standard library, a dependency on the full package (python3, perl) seems warranted, and that will usually pull in the interpreter package too. - 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. - for Ruby I only found guidance about application dependencies [2] but not module dependencies. The standard library seems to come with the interpreter here, so that's not a reason to depend on the interpreter package. Still, almost all ruby-* packages do depend on ruby | ruby-interpreter. - Perl has the split between perl-base (which has /usr/bin/perl) and perl (which is the recommended way to pull in the standard library). Almost all the pure-Perl modules in the archive Depend on perl. The Perl Policy [3] mentions that the standard library is the reason for the perl dependency. - Node.js ships the standard library with the interpreter. The policy [4] only mentions a build dependency on nodejs, but almost all the node-* packages also have a runtime dependency on that. Not sure if there's some specific reason for the runtime dependency? - for PHP, there apparently used be a draft policy but it's gone with Alioth now. The remnants I could find [5] don't mention package dependencies. Looking at the archive, I see pretty much uniform dependencies on php-common, apparently for enabling the module in the maintainer scripts. These dependencies do not pull in the actual PHP interpreter. [1] https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html#dependencies [2] https://wiki.debian.org/Teams/Ruby/Packaging#Handling_of_shebangs [3] https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module-deps [4] https://wiki.debian.org/Javascript/Nodejs/Manual [5] https://web.archive.org/web/20170906020218/http://webapps-common.alioth.debian.org/draft-php/html/ -- Niko Tyni nt...@debian.org
