Re: libraries depending on interpreters
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
Re: libraries depending on interpreters
On Sun, Nov 17, 2019 at 04:39:46PM +0200, Niko Tyni wrote: > - 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. FWIW we considered dropping this dependency, and it wasn't done so far mostly due to inertia. signature.asc Description: PGP signature
Re: libraries depending on interpreters
> It would be nice to get some input on this. For Java the library packages never depend on the runtime. Only the applications depend on a runtime package (typically java[0-9]+-runtime | default-jre). And in general we avoid mentioning the dependencies provided by the environment executing the code. For example, a library using the Servlet API will not have an explicit dependency on libservlet-java, because the dependency is necessarily pulled by the Servlet container running the code (Tomcat, Jetty, etc). Emmanuel Bourg
Re: libraries depending on interpreters
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
Re: libraries depending on interpreters
> On 17 Nov 2019, at 22:39, Niko Tyni wrote: > > - 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. The php-common dependency is for C modules (PECL) and is mostly generated by dh-php. There was a circular dependency before that I managed to unbreak. It’s little bit weird, but it works. The PEAR and code in PHP should generally depend on: - php - if it’s a web app - php-cli - if it’s a console app The „php-cli“ gets usually pulled with „php“ (whatever satisfies the meta package dependency). But I never packaged PHP applications myself, I just made sure the transitions between PHP versions are mostly smooth in Debian (packaging stuff, not language itself…). - There’s an obscure embedded PHP, but people using it know how to depend on it Ondrej -- Ondřej Surý ond...@sury.org
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 nt...@debian.org
