libraries depending on interpreters
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 ntyni@debian.org
Reply to: