Hallo Dalibor,
* Dalibor Topic wrote:
[mention how the unfree VMs should be used]
>I do not quite understand: do you simply want to list the VMs available in
>debian at the time of writing, and include references to non-free VMs not in
>debian?
I want something so that users take one way to include nonfree JVM. ->
mpkg-j2sdk. This should cover
* Names: jre-version-vendor or something like this.
Basicly it should say: Use mpkg-j2sdk and you can ask the maintainer
to include your java, if it works.
Unfortunatelly I can't really put that into better words. But your
suggestion about putting it into the 'Advises' section is great.
>Your name is missing here. You rewrote the whole thing, you should take the
>responsibility ;)
:) I wil include it in the patch I wills end to java-common.
>> As we can't make sure, that a java programm or library will
>> run with all available java virtual machines all java virtual
>> machine are treated seperatly.
>There should be a sentence explaining why this is the case, as the common java
>marketing 'wisdom' is 'write once, debug everywhere', so if you don't want to
>get frivolous bug reports of the 'but it's java, it runs everywhere!' you
>should explain why debian developers prefer to be honest instead of relying on
>third party claims about compatibility. ;)
Any nice words to it? IMO, we shouldn't make that too long, as this si
actually not 'Policy', but more a 'preface'. How about rewriting that
to:
|Debian package managment relies havily on the fact that if you install
|a piece of software, it will work. This can't be satisfied by
|different java virtual machines, even sun derived ones, so that all
|java virtual machines are treated seperatly.
>> same API version as the virtual maschine, includes and
>> includes/linux, with the JNI header files.
>What is in includes/linux? Is there anything that's part of the JNI spec? If
>not, then it shouldn't be required.
Hm:
[EMAIL PROTECTED]:/usr/lib/j2sdk1.4/include$ find /usr/lib/j2sdk1.4/include/
/usr/lib/j2sdk1.4/include/jni.h
/usr/lib/j2sdk1.4/include/linux/jni_md.h
/usr/lib/j2sdk1.4/include/linux/jawt_md.h
/usr/lib/j2sdk1.4/include/jvmdi.h
/usr/lib/j2sdk1.4/include/jvmpi.h
/usr/lib/j2sdk1.4/include/jawt.h
[EMAIL PROTECTED]:/usr/lib/j2sdk1.4/include$ find ~/debian/IBMJava2-141/include
/home/jan/debian/IBMJava2-141/include/jawt_md.h
/home/jan/debian/IBMJava2-141/include/jawt.h
/home/jan/debian/IBMJava2-141/include/jni_md.h
/home/jan/debian/IBMJava2-141/include/jni.h
/home/jan/debian/IBMJava2-141/include/jvmdi.h
/home/jan/debian/IBMJava2-141/include/jvmpi.h
/home/jan/debian/IBMJava2-141/include/jvmmi.h
/home/jan/debian/IBMJava2-141/include/jvmras.h
[EMAIL PROTECTED]:/usr/lib/j2sdk1.4/include$ find /usr/lib/kaffe/include/
/usr/lib/kaffe/include/jni_cpp.h
/usr/lib/kaffe/include/jni.h
/usr/lib/kaffe/include/jvmpi.h
/usr/lib/kaffe/include/kaffe/java_lang_ThreadGroup.h
/usr/lib/kaffe/include/kaffe/java_lang_Object.h
/usr/lib/kaffe/include/kaffe/java_lang_String.h
/usr/lib/kaffe/include/kaffe/java_lang_Thread.h
/usr/lib/kaffe/include/kaffe/jmalloc.h
/usr/lib/kaffe/include/kaffe/java_lang_StackTraceElement.h
/usr/lib/kaffe/include/kaffe/java_lang_Throwable.h
/usr/lib/kaffe/include/kaffe/java_lang_VMThrowable.h
/usr/lib/kaffe/include/kaffe/jtypes.h
eclipse for example needs include and include/linux to compile swt.
With IBM it will probably only be include.
Don't know what I should make of it. Maybe another java-config entry?
>> They also must include a java-config file (see below) which
>> includes the variable declaration for JAVA_HOME, which points
>> to /usr/lib/name, ANT_BUILD_COMPILER with the short name or
>> full qualified classname of the java compiler,
>> ANT_BOOTCLASSPATH, which is a JARS-like list of the
>> bootclasspath jars and the JARS entry, with the jars needed to
>> run this java compiler.
>You could give an example here for jikes, as in how do I specify jikes
>as my ANT _BUILD_COMPILER and set up the ANT_BOOTCLASSPATH for some
>VM, as that's the tricky case because of jikes' class library
>wrappers.
Actually much of this will be hidden in the CDBS classes (I hope :)
Anyway, I don't thing that
ant -Dbuild.compiler=$ANT_BUILD_COMPILER -Dbootclasspath=$ANT_BOOTCLASSPATH ...
is that complicated. This would be something nice for the advises or a
FAQ, though-
>> Chapter 3. Advices to Java packagers
>I'd also add someting like 'Debian supports the free software community. You
>should make an effort to get your package to run with free java environments in
>debian, as it makes it accessible to more users. If you have problems getting
>your package to run with a VM, please work with the 'upstream' to resolve the
>issues, or find a workaround.'
I have no objections to this proposal, but I would like to keep my
proposal on the 'technical' side. If everybody is happy with that I will
include it. If anybody complains, is your call to make 'em happy :)
>And maybe something about the commitment to quality of java packages:
>'When you release an updated version of your package, please test if
>it still works with the packages it depends on, and if the packages
>that depend on it still work with the updated package. If anything
>breaks, please work with the maintainers and the upstream to fix it.
>Debian should be the best platform to use java on, and you can help
>this effort by making sure your package doesn't break things.'
Tricky. IMO this is a general advise, which doens't need to be
mentioned again. Debian just is :) If something does not work, it's a
bug and I have to fix it: with or without such a sentence.
This is also an issue, which I really don't want to have policy
*enforced*, as the work behind it (should the kaffe maintainer check
*all* the depending package, each time he does a upload?) is a lot and
if I miss one error...
Maybe it is better to try move to the general library handling, where
new SONAMES will result in new packages. I think that most library
developer will be clever enough to mention breaking API, even with
java :)
On another side, this could be formulated a little broader and more
along the line of your 'make it work with free VMs'. Or is already
included in that statement.
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
