I've had a look at this bug and I thing we should not fource a specific javac or java at our users. If they don't want to download a BD JDK, then this should be made possible.
It is just for building the package. I don't think that most users will rebuild the Java packages, especially since they are architecture independent. You also need a lot of -dev packages (and gcc) for rebuilding C and C++ packages, so that's the normal way.
IMO java on debian needs some helper programms:
This is surely useful for running the packages, but doesn't gain anything when you want to build the package. I think the package maintainer knows best which JDK is suited for building the package, so he should chose one.
* A skript which installs *any* jdk/jre-bin properly (mpkg-j2sdk is a start, but it doesn't work with IBM SDK1.4), including mozilla-plugins and so on. This should be properly advertiesed in FAQ, README, Mozilla Maintainer, etc
I think such a script should be put in java-common. Who wants to write one? :-)
* A system to get a classpath at runtime, similar to shlibs files at compiletime (if I haven't understood something wrong there).
This will not be easy, for example when there are conflicting versions of one package, like log4j: Your package might use log4j 1.2 but also depend on another library package which uses log4j 1.1 - how do you want to resolve this situation?
I think it's still the best solution if the maintainers of Java applications hard-code the class path in their startup scripts (or use something line /usr/share/ant/lib). Sure, that's more maintenance work but it's the only way that I currently see to guarantee a sane class path.
Stefan
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
