[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Java policy draft

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

Nice greetings,

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

Reply to: