> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
