[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PROPOSAL] 3. RfD on new debian java policy



Hallo Dalibor,

* Dalibor Topic wrote:
>> 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?

Yes, because the curent proposal makes nor difference between free and
unfree ones. If you will drop the unfree interface, it will not
anymore possible without hacking the /usr/bin/name startscripts.

>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.

Its about supporting a interface to this 'sun derived' JVMs. Without
this interface a user has to hack the apps itself to make this
possible. This will result in "some" users to download the source and
compile themself *outside* of the debian packageing system. So for
this users, we could also stop packaging java apps.

I will not propose any changes, which will not include a possibility
to use unfree VM without hacking startscripts or doing workarounds
like using a package outside of the packaging system or reordering
symlinks.

If thats the consensus here, that this should not be made possible, I
will stop proposing.

>Leave your attitude at the door when you enter the dojo ;)

I tried...

>> >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.

And that will possible with this proposal: All debian packaged apps
will be tested and used 'directly' (=not via any alternatives). *only*
the 'sun derived' JVM will be used via a interface. 

>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.

I would like to do that. Unfortunatelly java isn't perl, where tehre
is only *one* interpreter. We have to deal with severyl interpreters
and I'm not going to see, why we have to force our users to use a free
one.

>> 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.

Someone told the story about ant and free tools. Eclipse is tested
*only* on IBM and sun. AFAIR, in the german java newsgroup noone tests
their software on a free alternative.

[/usr/bin/java just prints a explaining message]

In the first version of this proposal, I droped /usr/bin/java. Somoen
complained, because 'java helloWorld' would then not work. So I said,
that it may be setup, but must not be used by packages. I consider
this a good compromise and until some other consensus is showing up
here, I will keep it that way.

>> [ant and javadoc]
>> I've seen tora in some comments of the javac delegates. Maybe he has
>> some contacts to upstream.
>How about submitting a bug report?

I can't do everything.

>> >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? ;)

Aehm, yes...

>> 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? ;)

Yes, but what if I have a VM installed, which will work with every
app, which I will throw it it and then I need kaffe because of
java_app1 and sablvm because of java_app2 and gij because of java_app3.

>> >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.

funnily, I BuildDepend: on bd java, but my package works with any 'sun
derived' java, as long as I set JAVA_HOME to the right location.

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."



Reply to: