On Tue Jan 29 17:45, Eric Lavarde wrote:
> POINT 1:
>
> I would suggest to modify the Java Policy along these lines:
> - the specific java runtimes listed before java(2)-runtime are the ones
> tested by the packager, and for which he's ready to stand up and make it
> work (the supported runtimes).
> - if a bug report is related to another java runtime and the bug can't be
> reproduced under the "supported" runtimes, the maintainer may reassign the
> bug report to the "faulty" runtime package.
The problem here, and what I disagree with, is that just because you
list them first, does not mean they get installed when you install the
package, nor that they are used when the user run it. I am strongly of
the opinion that whether `apt-get install package' produces something
which works should not depend on what you already have installed.
I think the problem here is partly a bad definition of `doesn't work'
and what java2-runtime is for.
I will also clarify here that I am only considering things which are in
the archive. All bets are off when you have non-packaged things,
although I'm not objecting to supporting them where possible and when it
doesn't compromise working in the archive.
If something _does not work at all_ with the free VMs I don't think it
should depend on java2-runtime. Firstly, it certainly shouldn't be in
main, since it requires a non-free or unpackaged program to run.
Secondly, even if you put "sun-java5-jre | java2-runtime" in the
depends, most people will already have java-gcj-compat installed, and
hence sun-java5-jre won't be installed, and the program will not work,
despite the depends being satisfied. I think this qualifies for a
Serious bug.
If there is something which _should_ work with java2-runtime, but
doesn't in practice work with any of the free VMs then you could file
bugs on them all and leave the package depending on java2-runtime, but
practically speaking this will still leave most people with an
inoperable program. Hence in practice, I think the definition of
java2-runtime should be `whatever java-gcj-compat supports' and anything
else should list packages explicitly (or, we should add more virtual
packages, see below)
When it is what this seems to be, it does work, it's just a bit ugly and
maybe some small features don't work, that would seem appropriate to
keep in main, but include a note that a different runtime might work
better. Followed, of course, by filing bugs.
A much better solution would be to define a better set of virtual
packages. I would go with:
- lowest common denominator (essentially the _intersection_ of Java
1.4 and whatever java-gcj-compat supports)
Every RE can provide this.
- sun java 1.5-derived
This would be provided by sun*jre, icedtea, anything produced
by java-package.
Possibly java-runtime and java5-runtime?
Packages would then either depend on: java-gcj-compat | java-runtime OR
{icedtea,sun-java5-jre} | java5-runtime
I think this split is warranted given the things we have in the archive
at the moment and the large difference between the free VMs and the
sun-derived ones.
Note that this also applies to the scripts or wrappers used to start the
program. I don't think they should depend on the current alternatives
setting of java, but should still work even if the package only works
with some VMs. I think jarwrapper needs some work to support all the
combinations, but can at least specify one specific VM.
Matt
--
Matthew Johnson
Attachment:
signature.asc
Description: Digital signature