Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Ean,
* Ean Schuessler wrote:
>We must come to terms with the fact that a Debian Java policy cannot be
>built with proprietary VMs in mind.
It is already (debian java policy, chapter 2.1):
|Packages that contain a runtime conforming to the Java 1.1
|specification should provide java1-runtime. Packages that contain a
|runtime conforming to the Java 2 specification should provide
|java2-runtime. If a package conforms to both, then it should provide
|both; however, packages that do not implement the methods from Java
|1.1 that have been deprecated in Java 2 must not provide java1-runtime.
|
|They should use /etc/alternatives for the name 'java' if they are
|command-line compatible with the Sun's java program.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Under this, kaffe couldn't add a alternative for /usr/bin/java, as the
-classpath option didn't work as the sun one.
|They should have a CLASSPATH predefined which include the needed
|runtime environment.
So kaffe was actually not policy complient, when a programm added a
-classpath.
>There is no "make it work" when it comes to proprietary software and Debian.
If we build a debian policy, which does not take into account, that
there are nonfree java virtual maschines (which many people will want
to use: browser plugin, swing java programms (bah), plain to big apps,
which are currently not working in free alternatives), than this is
plain stupid (sorry for the word, but that was my first thought I had
in mind).
I will not write a proposal, nor support any, which will leave out
this fact.
When I wrote my policy proposal, I didn't know how far away the free
VM were from being '100% sun java compatible'. I will write a sligthly
different proposal, which makes it clear, that the virtual packages are
there to build a interface, so that ~100% sun compatible JVM can be used
from our packages. This will leave out free VMs, which have to be
handled independently from that (which should be ok, given the fact
that we control, which version we have and how that package works)
>>From the Social Contract:
>"We will support our users who develop and run non-free software on
>Debian, but we will never make the system depend on an item of non-free
>software."
Yea, and thats why most of the java packages are in contrib. We have
also motif software, which is also 'somewhere' in debian.
Or are you going to file removal requests against motif programms,
eclipse, tomcat and other java packages?
What I want is a well defined API, so that our packages can use such
nonfree JVM. This doesn't mean, that we depend on this non free (apaart
from the package, which are not working with fre alternatives), but
that we are open to the fact, that there are other solutions.
>Let's try to keep the discussion in that framework.
I hope you can understand, why I don't want to do that.
[almost fullquote snipped...]
Please don't do that, I always have to scroll to the bottom until I
see, that nothing more was written. This is a waste of time.
Nice greetings, Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: