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