Hi. Further on this proposal: > Java libraries must depend on the needed runtime environment > (java1-runtime and/or java2-runtime) ...
I do not like deleting this requirement. Although there are some serious problems with it (such as different libraries working to different degrees on different JVMs), removing this dependency will not solve these problems - it will in fact give the user *less* information regarding what they require. These java1-runtime and java2-runtime dependencies do at least tell you whether a library requires java2 core classes or not. > It's almost impossible to determine if a library works with > java1-runtime and/or java2-runtime. It at least as feasible as determining whether an application works with java1-runtime and/or java2-runtime. Certainly it should be clear which classes are used by the library (try compiling it against different java APIs). > For example, tomcat4 > can now be run with Kaffe 1.1.3 so a lot of libtomcat4-java's > dependencies actually work without a full "Java 2 runtime > environment" although they depend on "java2-runtime". This is because java2-runtime and java1-runtime are very loosely specified dependencies. Removing them will not help fix anyone's broken java installations. If tomcat4 needs java2 in most cases but works with kaffe regardless, why not just add kaffe as an optional substitute for java2-runtime in this case, i.e., have tomcat4 depend on (kaffe | java2-runtime) ? > 3. Depending on java-common (IIRC this was mandated by a previos version > of the Java Policy) is also not needed Agreed. Note however that it was never required by libraries in the first place. IIRC it's only required for JVMs. Sure, the libraries require JVMs but so do applications. If you want to make java-common optional, you should amend the "JVMs require java-common" clause, not delete an essentially unrelated dependency (libraries require a JVM). > 4. Libraries are supposed to work with any JVM so depending on > known-to-work JVM packages is also not sensible: Asking libraries to just depend on nothing at all will again not help fix anyone's broken installations. Note the difference between JVMs and java core classes. Libraries are supposed to work with any JVM, but they still require a particular version of the core Java API, which is what the java1-runtime and java2-runtime dependencies attempt to describe. IMHO, removing the "libraries require core Java classes" dependency is like removing libc6 from the dependencies of a C library. Quite clearly the libraries will use core Java classes, so I would argue this relationship should be made explicit. > To summarize: I'd like to move the task of determining the actual > dependencies to the packagers of Java applications. I'd argue this is definitely the wrong approach: 1) Libraries are not just for use by other debian apps. People use them in their own custom software as well. In this case, the only place they're going to get the right dependencies is from the library package itself. 2) As an application packager, you know what libraries your app uses. You shouldn't have to know the external libraries in intimiate detail as well - in particular you shouldn't have to chase down what classes are used by the libraries but not by your app itself. An example here is KDE packaging - you generally build-depend on kdelibs4-dev, but you rely on the fact that the kdelibs maintainers have tracked down the multitude of other libraries that kdelibs uses for itself that will also need to be installed. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
