Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Ben,
* Ben Burton wrote:
>> >I'm not really comfortable with the idea of "don't test, just assume it
>> >works until someone tells you otherwise". Yes, it happened with flex
>> >but that was a once-off. With this java proposal it will become
>> >institutionalised.
>> It is already institutionalised.
>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?).
>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.
I also didn't say, that you should make a claim that your package runs
on any of the 'debian included' VM. You should test them and only add
them, if it works.
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.
>> Lets say it this way: user wants a browser plugin (this is IMO still
>> the only thing, which they know as 'JAVA' (sic!)). So they will go to
>> sun and get the -bin download. Then they will hopefully look into a
>> FAQ, which will (someday) say, that they should run mpkg-j2sdk (or
>> mpkg-java, if it becomes that flexible) on the downloaded -bin and
>> dpkg -i the resulting packages.
>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.
>make their *own* JVM packages
Pretty easy nowaday with mpkg-j2sdk. Even easier, when this app will
work with JREs and use the new policy.
>and then use these exclusively for java on
>debian?
There will be some users, who pull in 'java', because they have to
satisfy a 'Depends:' or because they want to use applets. They will
never bother to check, what apt-get got for them, as long as it works.
>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.
>Btw, one of the great strengths of the main debian policy is to ensure
>that packages interact properly even with unusual systems or
>installations. So even if "most users" will just exclusively use a
>hand-rolled non-free JVM package, I will argue that the java policy
>should also work well for those few users who actually do things the way
>that we suggest they do, i.e., install a pre-built JVM package (or
>packages) made by one of the official debian packagers,or get their
>JVMs through the dependency system
And this will not work with this proposal?
>(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?
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.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: