Hi (I CC the debian-java list)
On Fri, Sep 20, 2002 at 02:47:07AM +0100, Alex Blewitt wrote: > o java-compiler, java2-compiler: I don't think it's necessary (or even > desirable) to distinguish between java and java2 at all, especially as > the '2' trademark doesn't have any sensible correlation between the > version numbers. It was basically a trademark that Sun used to Well I can agree on that. > encourage uptake of Java in business. I'd suggest having java-compiler > and java-virtual-machine, and then use the version numbers (1.2, 1.3, > 1.4) to denote different systems. If there are any specific > requirements on Java apps they can then distinguish it by >= 1.2 > instead of relying on java2. [I also don't know of any java1-only > systems either :-)] I'm afraid that is not possible with the current virtual-package system and dpkg, apt-get and dselect. There is no such possibility. :( I have requested it (I think) but that will probably not be available for a number of releases... > o Java programs in /usr/bin - how does this relate to java packages? If > I have a class com.ioshq.Test, then it expects to be in a directory > structure com/ioshq/Test, which doesn't fit in with the /usr/bin policy > described. Also, some executables are JAR files (which I don't know if > they count as executables) though it could be advisable to create > scripts to launch common apps, and put them in /usr/bin You have to have the executable in /usr/bin. As policy says it should be a wrapper to execute the java program. Is it unclear? > o Java libraries. Many Java applications need both JARs, but also > access to files (configuration files, workspace etc.). This policy True. > doesn't seem to address that. It would be better if a directory was It does not because the "normal" policy do that in a quite good way. > used with a well-known JAR file was included, such as > /usr/share/java/xerces/xerces.jar, which can then have other > non-polluting config files as well. Note that a JAR can refer to other Why? > JARs in the Manifest (using the Class-Path property) and generally do Yes java2 can. Not java1. This is a big problem in fact. > so by expecting a <name.jar> to be available. Using the proposed > packaging name guidelines, it is likely that most JARs will not be > usable after this approach since the system will not be able to find > those names. I do not understand this? The package maintainer have to make sure that the manifest file is correct, right? > o Use of different versions - some packages may depend on xerces1, some > may depend on xerces2. Can this be resolved in a neat way using version > numbers, or does the package have to be removed? You have to have two different package (as right now). > o JNLP - this has not been discussed in the Java Policy, and packagers > should probably be encouraged to create JNLP interfaces for their > programs. What is JNLP? > Hope this is useful; if you want more detailed explainations of the > above points then please drop me a mail and I'll try to be a bit more > descriptive. It is always useful to get new information about this matter and I really appriciated all feedback I can get. Especially constructive as yours. Regards, // Ola > Alex. > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
