Re: Java policy draft
Sanghyeon Seo wrote:
I just finished reading http://wiki.debian.org/Java/Draft
Me too. :-)
Please define, what it means to provide a virtual package. From the
context of the document, the only *garantee* this provides makes is "you
can develop java programms with this" or "you might be able to run some
java programms with this". This means they can't be taken for package
To be usefull, I would expect something like
/usr/bin/javac alternative with commandline compatible with...
/usr/bin/javah alternative with ...
The same should go for each alternative, as otherwise scripts might break.
This is the same as the sh alternative: /usr/bin/sh only garantees the
sh interface, not bash. But you can read, what's behind this garantees
in the man pages or POSIX.
IMO, its ok to leave the different sun derived java out of the policy,
as most of packaged stuff will work anyway and something like a tomcat
is anyway not touched by this document. But make it easy to replace the
classpath based JREs/JDKs with sun derived ones.
Some package must also provide a symbolic link from
packagename-extraname.jar to the most compatible version of the
available packagename-extraname-version.jar files.
I couldn't find a use case for this. For arch any, this is provided by
the -dev package. It should not be used for symlinking aka "linking"
(eclipse,etc), as it means that a wrong version can end up in the place.
It also means, that you need alternatives for this (think two different
version needed by tomcat and eclipse).
I'm not sure whats the gain for building packages. In my experince, you
anyway have to link in the jars by hand at build time, so it isn't so
different to link in something-1.3.jar or something.jar.
Plugins are not covert in this document, but are real common. Maybe it
would make sense to add a chapter on this how to package them (Naming, etc)
[JVM finder and CLASSPATh builder]
IMO it would make great sense to add a jpackage like "CLASSPATH" builder
and JVM finder and add the experience with this to the java policy. Up
to now, the java policy is mostly about packaging, but not about how
(participant of the 2003 discussion about Java policy...)