Re: Java policy draft

[Jan Schulz <jasc@gmx.net>]

Hi You,

Sanghyeon Seo wrote:
> I just finished reading http://wiki.debian.org/Java/Draft

Me too. :-)

Some comments:

[Virtual packages]
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 
dependencies.

To be usefull, I would expect something like
Classpath-sdk:
 /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.

[Java libs]
<quote>
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.
</quote>

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]
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

Nice greetings,

Jan
(participant of the 2003 discussion about Java policy...)