Re: [PROPOSAL] 3. RfD on new debian java policy
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> 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
For me 'Java' stands for a Trademark owned by Sun. They have some specific
rules regarding its usage here http://www.sun.com/policies/trademarks/#JavaTM
If I'd have to pick a name for a program which runs java byte code, I'd avoid
any of Sun's trademarked words listed here: http://www.sun.com/suntrademarks/
and use something like runjbc, as in run-java-byte-code.
> >> 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.
But it is already possible, isn't it? I can download tomcat from jakarta, and
build it with ant, and run it with a non-free VM if I want to. My Debian shell
doesn't kill my tasks when I try to run a non-free VM. Your proposal goes
further than that, it's about making sure that java apps run on non-free VMs,
it's about requiring these apps to suuport the legacy, non-free VMs. That's
where the DFSG and your proposal part their ways, according to my understanding
of Mark's argument.
> >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'.
Leave your attitude at the door when you enter the dojo ;)
> >> 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.
I'm not convinced this separation is necessary along the lines of some vague
notion of completeness. I am, on the other hand convinved, that the packager
should be able to separate VMs in those that will work with the package, and
those that may not. I just don't think this separation should be made on the
basis of advertising materials (look, a shiny new API is here!), but instead on
what VMs have been actually shown to work with the package. That's the
difference between pretending that a package 'just works' because a readme says
so, and actually testing the package and honestly telling the users that the
package really works with some VM, since the packager has tested it.
> Most java apps are designe for this unfree VMs. If a app 'wants' a
'Most'? 'Designed for unfree VMs'? A quick google.de search on 'designed for
JVM' shows no applications claiming that in the first 40 hits. I'd expect
better results if what you're claiming was true.
I have the impression that you pulled this one out of your wizzard hat ;)
> If you have a different naming, please say so. I'm also not satisfied
> with this names...
I'd call what you claim to be both 'non-free' and 'compatible' scsl-derived, as
that's the non-free license Sun puts their VM code under.
> >> 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.
If a maintainer doesn't want to get his hands dirty by installing a prorpietary
VM (for example because he doesn't want to give Sun and their business parties
to snoop his computer as they wish, as in this section of Sun's Java 1.4.2_01
license:
SOFTWARE FROM SOURCES OTHER THAN SUN. You acknowledge that, by your use of
optional features of the Software and/or by requesting services that require
use of the optional features of the Software, the Software may automatically
download, install, and execute software applications from sources other than
Sun ("Other Software"). Sun makes no representations of a relationship of any
kind to licensors of Other Software. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO
EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA,
OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES,
HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED
TO THE USE OF OR INABILITY TO USE OTHER SOFTWARE, EVEN IF SUN HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES. Some states do not allow the exclusion of
incidental or consequential damages, so some of the terms above may not be
applicable to you.
) then you propose that he should tell his users that the software will work
with some non-free VM without being able to test it. I think that's dubious
practice, really, and if I was a debian package maintainer, I wouldn't like to
be forced by a policy to make claims that I can't verify.
> 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.
give them shell scripts that print a message like
Dear User,
you surely expect to find a java(c) executable, that does something meaningful,
for whatever you consider to be meaningful. We've tried to come up with a good
idea about what you may consider to be meaningful, but our mind-reading
abilities are underdeveloped for this task and the definition of meaningful
seems to be different for everybody involved. So in order to get a working java
environment, you have the luxory of choice to pick one of these fine free
environments to do your java work in and install it:
* a
* b
* c
If you chose to use a non-free java VM, consult the debian non-free java faq
available here: some URL.
best regards,
the debian java policy makers
> [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.
How about submitting a bug report?
> >> 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
That's still a silly definition. Run every java program in debian, o.k. that
something we can work with. Run *every possible* java program is pointless as
no free or non-free VM can do it.
> [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.
I've never seen a bug report from you on the kaffe mailing list, sorry. I'd be
very interested in having someone (and you as the debian packager would be
ideal) help us get eclipse to run better on free VMs, be it kaffe or gij. If
you have problems with eclipse on kaffe, tell us more about it on the kaffe
mailing list, and we'll try to fix the things for 1.1.2.
> >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?
Why does that matter? I have a car already, why don't they build a highway to
my house? ;)
> Just for the sake of downloading 10+ MB again?
It will hardly matter compared with the download sizes of the non-free VMs,
will it? ;)
> >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.
which is fine, if they need that to build.
If I want to rebuild tomcat, then I'll better download BD java since that's
what's been used to build the thing, and it actually worked. If I'm feeling
lucky, I'd try to build it on Sun's VM or IBM's or gij, but I don't see the
need to bother the maintainer with caring about the other VMs if he's already
stated his build dependencies.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: