Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Ben,
>
> * Ben Burton wrote:
> >Yes, but in the old policy it's clear that we don't really know what
> >works and what doesn't. In the new proposal, we claim to specify
> >precisely which VMs work with which package, and so if we encourage
> >maintainers to make such claims without actually testing the different
> >VMs, this will be come a kind of "institutionalised dishonesty".
>
> The only 'claim' they have to make are that 'unfree' (sun derived or
> whatever the best name now is) will work. This is a claim, which I
> haven't found disproofed (sp?).
Then why did the ant developers have to release ant 1.5.4 to deal with breakage
of their javah task in Sun's java 1.4.2 if sun derived VMs will work so well?
Because it can *not* be assumed that things will work well without testing
them, especially when you don't care much about the java API specs like ant
developers seem to. Assuming that things will work on non-free VMs doesn't work
in the real world.
> >Let me make it clear that I'm not arguing against your JVM dependencies
> >per se. I'm arguing against the proposed method of maintaining these
> >dependencies, which is "don't bother testing packages across JVM changes,
> >just wait for the bug reports".
>
> So what? I just compiled kdelibs4, to get the -dev package working
> with experimental Xfree4.3 (xlibs-pic -> xlibs-static-pic). It took me
> half a day (yes, that was my first such compile problem...) to figure
> out, why it didn't configure on my newly installed unstable. Until I
> saw how the kde_qtsubversion variable was initialised: it is set in
> all cases to '1', but the latest qt version in unstable is '2'. I don't
> think that anyone bothers to test their packages, when one of the
> dependencies changed.
Whoever changed the dependency should have tested the packages that depend on
it, in my opinion.
> What I say is, that you can assume, that if you compile your java
> package to java byte code (version ...), then a 'sun derived' VM will
> run it. I consider that save enough and a lot of better than the
> current practise.
There are examples available that clearly show that this assumption is not
valid.
> >Right, so you just expect users to download a JVM directly from sun,
>
> No, I don't expect all users doing this. Most will pull in a JVM via
> apt-get. But until a browser plugin is packaged for debian and will
> work good enough (awt and swing classes in the free one?) a lot of
> people will want this 'sun derived' JVM to access their bank accound.
I want to access their bank accounts, too. Where I can I get that cool
bank-hacking VM? ;)
Seriously, though, you'll find that kaffe comes with an appletviewer program
that works fine with a lot of AWT applets out there. No Swing yet. And no
browser plugin yet, although some code for a mozilla plugin exists, and there
are some proposals to integrate kaffe with konqueror.
> >So why bother making a Java policy at all?
>
> So that the above is also possible.
>
> If we don't include the 'sun derived' JVM, we can reduce the java
> policy to a simple 'put your jar files into /usr/share/java and name
> them ...' All the rest could be managed by the normal debian policy.
> Everything whats more in the current policy is IMO not working to
> ensure that java package will work.
That's somewhat contradictory to your policy, isn't it? It spends a lot of
space on 'sun derived' JVMs, which are not included in debian anyway, so it's
not really working to ensure that java packages will work. ;)
> >(and thus quite possibly have several
> >JVMs installed as described above).
>
> So you find it acceptable, if one has 5 java packages, which need 5
> different JVM, *althought* one of this JVM will run all 5 packages?
Of course. I may want to run one package on one VM, the other one on another,
because it performs better on it, for example. What's wrong with picking the
right tool for the job? What's wrong with having a choice?
Beside, you could always try to build the package yourself with the VM you have
installed already, test it, and then try to convince the maintainer to include
it in the build dependencies. Although your 'no need to test with all sun
derived VMs, it should just work!' position could undermine such claims
slightly ;)
> I'm still behind a ISDN line, so download time matters. I also don't
> have another hundred MB HD place just to satisfy package dependencies,
> which would be satisfied by only one package.
Then it should be up to you to collaborate with the maintainers to make sure
their packages build on the single particular VM environment you decided to
pick for yourself and to aid them in providing support for it. It shouldn't be
the other way round, in my opinion. Maintainers shouldn't have to support every
random VM someone downloads off the net, just because that's the one the
particular user is stuck with. They should support the VMs that work with their
packages.
I mean, I like kaffe, for example, but I don't demand that debian makes a
policy that requires all java package maintainers to support my favorite VM. If
I care about running a particular application of kaffe, I don't see a problem
in getting in touch with the maintainer, and helping him support kaffe
(better). In fact, I've been doing this for more than a year, though I prefer
to work with the upstream, where the actual decisions are made ;)
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: