Java policy draft

[Sanghyeon Seo]

I just finished reading http://wiki.debian.org/Java/Draft

In virtual package names, sdk is used instead of jdk. They should
be consistent.

Seo Sanghyeon

Re: Java policy draft

[Andrew Haley]

Re debugging info -- I put this patch into ecj on Fedora:

https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00086.html

This patch means that no matter what broken debug options are in Ant
scripts, every Java program in an RPM has full debuginfo.
Essentially, this turns a rule You shall do this into something
automatic.

Andrew.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Java policy draft

[Andrew Haley]

Andrew Haley writes:
  Re debugging info -- I put this patch into ecj on Fedora:
  
  https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00086.html
  
  This patch means that no matter what broken debug options are in Ant
  scripts, every Java program in an RPM has full debuginfo.
  Essentially, this turns a rule You shall do this into something
  automatic.

An alternative would be to have ecj abort if debugging isn't set when
building a package.  This would be the brutal alternative, but it
would work.  I suspect that unless you do *something* automatic to
enforce the policy, it won't work.

Andrew.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Java policy draft

[Jan Schulz]

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...)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]