Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Mark,
* Mark Wielaard wrote:
>I am afraid we are not communicating very constructively.
>We might have to start from scratch since somehow we keep missing each
>others points.
Seems so. To sum it up:
* I want to have the possibility to use unfree VMs with java packages
* you don't want to include that.
>On Mon, 2003-09-08 at 20:15, Jan Schulz wrote:
>Sorry? Above I explain how to get eclipse running with an INTERPRETER
>since you seem to like that more but you keep on arguing against native
>compiled code. Immediately after this paragraph you quote I say:
Sorry for the words, but I was quite fed up :) I upgraded to unstable
last night and and it went terribly poo-shaped, as I had to many
backports installed.
So, going back:
> The point that I am trying to make is not that you should do it
> all by compiling to native applications and libraries (even
> though I think that will be the future). If you think that goes
> to far, to fast then everything that works by compiling to
> native code will also work by compiling to byte code and then
> use a free byte code interpreter. When you do that you might get
> a better policy. Just look at what free applications and
> libraries there are written in the java programming language and
> see what is possible at this moment with free tools that Debian
> can actually package and distribute.
So you mean that the policy should mandate that a packager is trying
to compile to native and see whether it will work?
>> And? If the users chooses to do so, it's their choice. I don't think
>> that we should *force* them not to.
>I didn't say that you should force anybody to do anything.
>I just pointed out that there is a cost associated with the choice.
>A cost that I think is to high for people who choose Debian because of
>the DFSG.
What? If you don't want to install any unfree VM, then simple don't do
it? Apt will find no installed 'sun derived'-VM, so no virtual package
to satisfy the 'sun derived'-interface and so will automagically pull in
the right packages from main.
If a program can't be run with 'only main' java libs, then it will go
to contrib and so will be hidden from a user, who chooses not to
install 'such stuff'.
So the *only* thing which this policy proposal adds, are that
packagers should assume, that java apps will work with 'sun derived'
java virtual maschiens and add two things:
|Depends: kaffe | gij | java-runtime-1.4, ...
and a additional entry in their startscript:
|for j in /usr/bin/kaffe-1.1 /usr/bin/gij-3.3 /usr/bin/java-1.4 ; do
| JAVACMD=...
|done
They have to test the kaffe and gij entry (in this case), whether
they will work. The packagers can assume that the 'sun derived'
interface, if it exists, will run the package.
>> But they still have to comply to the debian policy and in this case
>> the debian java policy.
>You seem to be satisfied with a policy that is only really useful for
>contrib and non-free.
No, this policy is IMO usefull for debian. It makes migrating from
'contrib' to 'main' easier, as both should work the same. It also take
the fact into account that there *are* some people, which won't refuse
to use contrib/unfree.
>Two things which are not part of Debian (and which
>I personally have never even used).
I have and I will continue to use it. And I don't want to have a java
policy, which refuses this fact.
>So lets just agree to disagree on
>the importance of this policy.
If for you the most important fact is, that this policy makes it *not*
possible to use a 'sun derived' JVM, then, yes, we disagree.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: