Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
>> The problem in debian is to find out this java.
>> This should be adressed in this proposal.
>Why this fixation on this one program name?
Do you have a better name for 'programm, which runs java byte code'?
for me 'java' stands for exactly this and I don't midn if it is
actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java
>> This proposal tries to eliminate the problem how to get a working
>> "java"-command, which is able to run the java application. It also
>> adresses the build environemnt, so that java packages can be compiled
>> to java byte code and so on.
>Which is a good goal. But I am puzzled why you think you need to
>recommend and advocate proprietary tools for that.
I don't do it. I just see the need, that some people will want to run
java apps on a unfree VM. This propsal makes this possible.
>Not if you use the native gcj version.
Yes, *if* I do that. Currently I have not done it and this proposal is
not about compile to native. And yes, I'm also biased towards 'not to
compile to native', comming from a java newsgroup, where the question
of the ay was 'I want a exe from my java app'.
>This looks like a problem only made worse by the java-policy since that
>says that there must be a /usr/bin/java program. Normal packages should
>not rely on that and should work out of the box when installed. I don't
>completely follow why you think that installing some random proprietary
>non-free, non-debian package will suddenly break normal packages unless
>those packages have bugs (like depending on /usr/bin/java while they
>shouldn't).
Not that I didn'T say that. The only thing I say is, that nothing can
tell me, where /usr/bin/java points to. Eclipse needs (still) a unfree
VM, so if /usr/bin/java is sableVM, I will get a nice bugreport that
'eclipse doesn't work'. Under the current policy (BTW, have you read
it?), the only thing I can do about this is 'set JAVA_HOME' and close
the bug.
>> The 'unfree interface' is a way to access unfree JVM. It's also a
>> attempt to seperate 'incomplete' (spec and API wise) JVM from complete
>> ones.
>Which is a silly separation. There will never be "complete" free ones if
>you insist that complete means precisely like the one and only
>proprietary one.
But it still the only seperation we can make without getting into a
'virtual packages hell' like we have discussed early in this thread.
Most java apps are designe for this unfree VMs. If a app 'wants' a
unfree one, we can do two things: satisfy this depends (-> unfree
interface) and test whether a less complete VM will also work.
If you have a different naming, please say so. I'm also not satisfied
with this names...
>> I will neither propose nor agree with a debian java policy, which will
>> ignore this facts and make out users patch debian packages to get this
>> working.
>I don't see the point of making a policy that says that packages must
>work with some non-packaged non-free programs. It would be nice if they
>do, but requiring it is a lot to ask of a packager.
ot of the box, they work with the VMs, which are stated in the
readme/webpage. So we can assume that a package will work with one of
the 'unfree interface' versions. If we get that for free, I don't se
ethe point in denying this fact to the user.
>> Any proposals? IMO the above is good enough for debian java policy. As
>> the proposal says, /usr/bin/java is not meant to be accessed by
>> packages.
>I propose to not define it in the policy at all.
>Except maybe as a note saying that in the past there was a alternative
>system for /usr/bin/java and /usr/bin/javac but it didn't work out.
I can put a stronger note in there, that this alternatives are not to
be used by packages and are there for backward compatibility and for
the user to try out 'HelloWorld.java'.
I think removing them completely would be the best, but I think that
too many people will complain if the don't have a 'java/javac' in
their path.
[ant and javadoc]
>> Please also note, that I currently don't have this 'some afternoons'.
>Fair enough. But these are things that should be discussed with upstream
>to make Ant usable on a Debian system.
I've seen tora in some comments of the javac delegates. Maybe he has
some contacts to upstream.
>> Run every program as good as the unfree ones?
>Every program :) Maybe we could start with a subset of that.
For debian package dependencies, it needs to be 'every'... IMO
>What doesn't run satisfactory for you?
eclipse?
Please note: It doesn't even run 'good enough' for me on a unfree one :)
[full load server with kaffe/gcj tomcat]
>Yes, why not? Maybe Dalibor has an example of kaffe.org which I
>believe runs Jetty on kaffe.
Lets give this example: I develop webapps. Until now they were able to
run on kaffe/gij/gcj. Now I want to have some pictures put into the
pages and I will use Image to get the size (yes, I know that tehre are
better ways and that this is too slow). I deploy this. Crash. I will
search the net for 'Image tomcat linux' I will get a lot of results,
which points to 'headless mode' for awt available in 1.4. I put the
right things into the tomcat startscript. Crash again.
And this is only tomcat with some small webapp.
>But if they are packaged for Debian cann't you just backport the build
>tools also?
Yes, but why should I if I have a full sun J2SDK installed already?
Just for the sake of downloading 10+ MB again?
>And packages out there which do not work with free tools are
>probably not packaged for Debian anyway since they would have to go into
>non-free or contrib.
Currently almost every java app is in contrib: eclipse, tomcat, ant.
>I do expect Debian to have a packaging system that won't give me
>headaches. And I know that is does have that.
Yes, because tomcat and eclipse build-depend on BD java.
>it simple at all. I still don't understand how this interface is
>defined. All I see is some hand-waving and pointing to some
>(unversioned) proprietary package.
It is versioned, at least on API level. I don't think that we can do
more,given the fact that there are three different vendors and and a
lot of service releases.
>I just hope that you don't punish the Debian packagers that want to just
>package some things which happen to be written in the java language by
>requiring them to be interoperable with some unpackaged, non-free,
>proprietary stuff.
No I don't. Currently everyone *does* it with JAVA_HOME, but afterwards
only the 'unfree interface' should be used.
>But I am not a Debian developer so I cannot judge
>whether or not this java-policy is an improvement to the old situation.
Read the old policy. I think it was designed with mostly sun java
1.1.8 and 1.3 in mind.
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
