Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Mark,
* Mark Wielaard wrote:
>On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
>I would call it byte code interpreter then.
>Try to avoid the java name a bit since Sun claims a trademark on it.
>And it make it more clear that it is only one part of the environment
>that people might want. (The others being a byte code or native compiler
>and a core class library.)
'Byte code interpreter policy'... the "debian byte code interpreter"
mailing list. No, sorry, i won't do that.
>> Yes, *if* I do that. Currently I have not done it and this proposal is
>> not about compile to native.
>But I also pointed out how to get it working with a traditional byte
>code interpreter <http://www.klomp.org/mark/gij_eclipse/>.
But this is completely besite the point that we are here discussing a
policy for using 'java byte code interpreters'. If you want to have
'compiled to native' java packages, then file a bug against the
packages, which you want and ask the maintainer to do it. Packages,
which will do that will use the normal debian policy to do it.
>[...] If no -> it cannot be part of Debian and users will probably be
>better of installing the upstram source anyway together with some
>proprietary non-free vm/compiler/library combination.
You do know that we have a contrib and unfree section, to which this
policy also applys?
>> the 'unfree interface' versions. If we get that for free, I don't se
>> ethe point in denying this fact to the user.
>Since the user doesn't get that for free. They have to install non-free
>proprietary software which they cannot use according to the DFSG. They
>might even have to accept licensing terms which make it impossible to
>help others working on free replacements!
And? If the users chooses to do so, it's their choice. I don't think
that we should *force* them not to.
>That is a good starting point. I am sure that I or other gcj hackers
>would love to help you make the gcj compiled eclipse the best eclipse
>out there. Please bring on the bug reports!
I will do that, once I have time again to spend a complete weekend on
that. And after all the RH patches have made it into the gcc in
unstable.
>Because the packager (if it is part of Debian) as obviously tested it
>with free implementations that he/she nows work best with the package?
So consider a package, which requires a 'sun derived' 1.4 JVM.
Without the 'sun derived interface', it will always be the BD java
packages, which will be used. The only reason for this is, that the
packager knows the location of JAVA_HOME. Even if I install the BD
packages via the -bin download, it will not work, even if I use equivs
to satisfy the build depends.
>> Currently almost every java app is in contrib: eclipse, tomcat, ant.
>All the examples you list can soon move into main if the packagers make
>them work and test with free implementations. If Red Hat can do this,
>why can't Debian?
Because RH pays someone for this work? I will not simple drop eclipse
into main until I think it will work as good as I expect it. 'just
startup' is not good enough.
>> Yes, because tomcat and eclipse build-depend on BD java.
>Then those packages are currently not part of Debian...
>I don't see your point.
But they still have to comply to the debian policy and in this case
the debian java policy.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: