generally speaking, the JDK the package is built with *is* relevant,
if only to avoid java.lang.UnsupportedClassVersionError: for instance
your fix considers the JRE from sun-java5-jre to be acceptable, when
it definitely is not if the package is compiled with a JDK6 (which is
what will happen with the Build-Depends line you left as is).
The build depends line would by default be satisfied by
java-gcj-compat-dev and
I have confirmed that a binary built with that DOES work with the
sun-java5-jdk.
It would be an issue if building with sun java6 though and It probablly
does make
sense to explicitly specify a classfile version.
The solid fix is IMHO to ensure that you run the program with the JRE
associated to the JDK you used for building.
Yeah, completely ignoring the users JRE preferences is an easy fix, I
dunno if
that is considered acceptable or not
Otherwise, you have to
resort to using poorly-scalable solutions, like you did in
/usr/bin/azureus by trying to hand-select what JREs are appropriate or
not.
I didn't just "try to" hand select them, I tested all the sun based
jre's in debian
Another, more proper solution, would be for example to "Build-Depends:
java5-sdk" and "Depends: java5-runtime", but unfortunately
java-gcj-compat provides java5-runtime, which takes us back to square
one.
And even if it didn't provide it depending on a JRE does not provide any
gaurantee that the JRE you depend on will be the JRE the user/system select
as default. So if you want functionality that is not provided by every JRE
you need to either lock to one JRE or use a selection script like the
one I wrote
(this is something that should probablly be centralised but that is
something to
be considered post-lenny)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
