Bug#227587: [PROPOSAL] Java library dependencies
> Non of them even implements the full JDK 1.1 API so they also shouldn't
> provide java1-runtime unless you change the definition of the
> java1-runtime virtual package.
We've already had this argument. The java*-runtime virtual packages
are a loosely defined system for which Jan already has a much more
detailed replacement. IIRC it has already been agreed upon that in
the current (flawed) system, java1-runtime needs to be interpreted
"approximately". Being inflexibly precise about it as you suggest
means it will be useless for the purpose for which it is intended.
Sure, providing java1-runtime might mean you run into trouble with
a java app that requires AWT (for instance). But your proposal is to
simply remove all java*-runtime dependencies completely, so you
certainly aren't fixing this particular problem.
> > And there *are* packages in debian that do work with java1 alone, so the
> > use of java2-runtime does convey meaningful information.
>
> Which ones are these?
I invite you to try apt-cache showpkg. Btw, I maintain two of them
(jython and libreadline-java), both of which can be used as libraries.
> > For some people, the
> > political ideals are part of what draws them to debian. To add a library
> > package to debian and then say "it's broken but we don't care because
> > nobody should use it anyway" is absurd.
>
> I never said something like this! I just said that I don't recommend
> using Debian JARs in custom projects.
Fine. I say that if we're providing debian packages for java libraries,
we should at least take basic care to give them a chance of working with
custom projects. Just because you don't want to do this and just because
you might not care about freedom of software (use upstream JAR so you
don't have non-free/contrib material stripped out) doesn't mean others
will follow the same strategy.
As a debian user myself, if I want to build an app against library X,
the first thing I'd do is install the debian package for library X and
work against that. I certainly wouldn't think of a direct download from
upstream as my first approach.
> I suggest to use the original
> upstream JARs instead, especially when you intend to run your Java
> project on operating systems other that Debian.
If the debian packages are stripping out non-free material, your app
*should* run on other operating sytems that use the complete upstream JAR.
Building against a stripped-down library is not going to make your package
depend on anything outside the upstream library.
> Exactly. That's what my proposal said: "Java library packages must
> depend on other library packages if they can't be used without them."
> This is currently not mandated by the Java policy.
The core Java API is essentially a set of libraries as well. If a
library can't be used without java2 material, it must depend on
java2 core classes. Your proposal seeks to remove these dependencies.
> - No free class library currently implements the full JDK 1.1 or
> JDK 1.2+ API.
We are currently talking about the pre-Jan world of poorly specified
APIs. In this world, a strict interpretation of java*-runtime can
only lead to tears. The complete solution is a complete reworking of
Java policy as Jan has suggested. I claim that severely restricting the
use of java1-runtime and silently ignoring all API dependencies is not
an appropriate solution in the meantime.
> - In some cases you simply don't know which JDK version a library that
> you want to package was written for. Which dependencies should you
> specify? You can't run your library to test this.
In most cases you can *build* your library to test this. Although
packages such as jython that use introspection require a little more care.
> You need an application that uses your library to test it.
So you're saying that (i) some libraries have no applications that use
them, but (ii) library packages should only be used by application packages
and not in custom projects? Then why bother packaging such libraries
at all?
> - java*-runtime are virtual packages. Packages are supposed to depend on
> "real_package | virtual_package". Which real_package should be chosen?
> Some packages have chosen classpath, others have chosen kaffe.
Where's the problem? The real_package is only used if the virtual_package
is not already satisfied. Once the first package providing java1-runtime
is installed, the rest of the (foobar | java1-runtime) dependencies will
be satisfied without further ado.
> libtomcat4-java packages will allow "kaffe (>= 1.1.3)" as first
> alternative dependency. But libtomcat4-java depends on
> libcommons-beanutils-java which in turn depends on java2-runtime without
> any other alternatives. So when I type "apt-get install tomcat4" kaffe
> is selected but you can't install tomcat4 anyway since the dependency on
> java2-runtime in not satisfied. You need to install external non-free
> packages in order to run tomcat4 with free software.
If libcommons-beanutils-java won't run under kaffe, then I'm sorry but
non-free packages *will* need to be installed. If it will run under
kaffe *or* the non-free java2, then I'm sorry but this must be specified.
Otherwise people will try to use it with sablevm or gij or any number of
other JVMs that presumably will not work.
I claim that failure to run is a greater evil than bloated install.
With the current situation, sure - it's more difficult to install a
minimalist system. But with your proposal (removing API dependencies
completely), it's more difficult to have a system that actually works
at all.
Ben.
Reply to: