Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> 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.
My proposal to have the maintainer depend his package on all the VMs that he
knows will work with his package makes no difference between free or non-free
either. Just between 'works' and 'who knows'.
> >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 regularly download and build the sources outside debian's packaging system.
The horror! Please everyone stop packaging java apps, your work is useless for
me ;)
> 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.
Which is not that different from what I'm saying, really. I just don't feel
that non-free VMs should have to receive some special care by the maintainers.
If the maintainer wants to support non-free VMs, I don't want to prevent him.
But to force him to provide support for them, would be wrong and force
maintainers to run non-free software. I don't think anyone wants that.
A better way in my opinion is to allow the user to 'override' maintainer's
choice of VM environment in some easy way (like putting another java executable
in front of his path, or running a selectmyvm script).
> >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.
But noone is forcing them ... if the package only runs on a non-free VM, the
maintainer can not force the user to run it on a free one, can he? If it runs
on the free and non-free ones, then a maintainer, who doesn't mind dubious
non-free licenses, will mark the package to depend on both the free and
non-free VMs that he knows the package will run with.
> >> 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
ant is not portable between java environments, as it uses sun's internal
classes.
eclipse uses unspecified JAVA_HOME, and is therefore not-portable between java
environments, free or non-free. If the maintainer (i.e. you) says it will work
with some VM, because he tested it, then if I want to run eclipse and agree
with that VMs license, I'll download that VM.
> *only* on IBM and sun. AFAIR, in the german java newsgroup noone tests
> their software on a free alternative.
My experience from the kaffe, gcj and classpath mailing lists is of course
different. there everyone tests their code with free VMs, and many people don't
touch non-free VMs.
> >> [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.
Then I'll submit one. You make sure the policy turns out well ;)
> >> 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.
that's an illusion, as there is a lot of corner cases where 'write once, run
everywhere' turns into a 'write once, debug everywhere' as anyone who's been
implementing something pushing the limits of java will tell you.
As another example, some API tests from mauve fail with Sun's VM because Sun is
not able to implement their specs properly. that's the reality, unfortunately
its quite different from Java marketing materials.
> >> >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.
Great, then if you've tested it you can make your package depend on IBM's java
and Sun;s java as well and make the lifes of those users who prefer to use
IBM's or Sun's java easier. Where is the problem?
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: