Re: [PROPOSAL] 4. RfD for a new debian java policy
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> I would like to include somewhere teh naming and way to include
> 'unfree' JVM, but I haven't found a proper place. I would like to make
> that a little more specific, so that we only use one way to access
> them (otehrwise there will be some people, who alien a rpm). Any
> suggestions welcome.
I do not quite understand: do you simply want to list the VMs available in
debian at the time of writing, and include references to non-free VMs not in
debian? You can put it in the 'Advice to packagers' section, as in 'these are
the java environments in debian, please test your packages with the free ones,
and work with the upstream to get them to run on as many as possible. some
users will want to use the non-free ones nevertheless, you can work with them
on getting your package to run on the non-free VMs. Note that you don't have to
touch non-free VMs yourself, you can delegate that task to users who don't mind
being bound by freedom-restricting licenses'
> The proposal:
> --8<---------:- snip -:---------8<---------:- snip -:---------8<--
>
> Debian policy for Java
>
> Ola Lundqvist
>
> Stephane Bortzmeyer
Your name is missing here. You rewrote the whole thing, you should take the
responsibility ;)
> 2.1. Java virtual machines and runtime environments
>
> As we can't make sure, that a java programm or library will
> run with all available java virtual machines all java virtual
> machine are treated seperatly.
There should be a sentence explaining why this is the case, as the common java
marketing 'wisdom' is 'write once, debug everywhere', so if you don't want to
get frivolous bug reports of the 'but it's java, it runs everywhere!' you
should explain why debian developers prefer to be honest instead of relying on
third party claims about compatibility. ;)
> 2.2.1. Ant Environment
>
> Packages, which can be used with ant to compile java code must
> setup a directory structure in /usr/lib/name (where name is
> the name of the corresponding java virtual machine (see
> above)), which includes bin/javadoc, which should be of the
> same API version as the virtual maschine, includes and
> includes/linux, with the JNI header files.
What is in includes/linux? Is there anything that's part of the JNI spec? If
not, then it shouldn't be required.
> They also must include a java-config file (see below) which
> includes the variable declaration for JAVA_HOME, which points
> to /usr/lib/name, ANT_BUILD_COMPILER with the short name or
> full qualified classname of the java compiler,
> ANT_BOOTCLASSPATH, which is a JARS-like list of the
> bootclasspath jars and the JARS entry, with the jars needed to
> run this java compiler.
You could give an example here for jikes, as in how do I specify jikes as my
ANT _BUILD_COMPILER and set up the ANT_BOOTCLASSPATH for some VM, as that's the
tricky case because of jikes' class library wrappers.
> Chapter 3. Advices to Java packagers
>
> Warning: These are just advices, they are not part of the
> policy.
>
> * Be sure to manage all build and runtime dependencies by
> hand in debian/control. dh_java makes this task a little
> easier. It can also setup the java-config file. The CDBS
> includes helper classes to handle ant based sources.
> * You can suppress many calls in debian/rules which are
> meaningless for Java, like dh_strip and dh_shlibdeps.
> * Source package handling is painful, since most Java
> upstream programs come with .class files. I suggest to
> make a new .orig tarball after cleaning them, otherwise,
> dpkg-source will complain.
> * Java properties files are probably better under /etc and
> flagged as configuration files (this will be integrated in
> the policy, one day).
I'd also add someting like 'Debian supports the free software community. You
should make an effort to get your package to run with free java environments in
debian, as it makes it accessible to more users. If you have problems getting
your package to run with a VM, please work with the 'upstream' to resolve the
issues, or find a workaround.'
And maybe something about the commitment to quality of java packages: 'When you
release an updated version of your package, please test if it still works with
the packages it depends on, and if the packages that depend on it still work
with the updated package. If anything breaks, please work with the maintainers
and the upstream to fix it. Debian should be the best platform to use java on,
and you can help this effort by making sure your package doesn't break things.'
But all in all, I must say that the policy has turned out quite nice faster
than I had expected it. Thanks for doing such a good job, Jan, and for being a
great discussion partner.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: