Hallo Stefan,
Do you want to be included in the reply?
* Stefan Gybas wrote:
>I think you are making the same mistake as Ben here: java*-runtime just
>means the core classes, no JVM! If you need both, you need to depend on
Hm, j-v-m us a even better exapmle for a policy redesign. Is there any
exepmle, that a runtime from one JVM works with another? The only
exemle I have ist using at compiletime to compile you package against
a certain runtime.
>> This requirement is even more flawed, as the only thing, which is
>> garanteed, but unfortunatelly by *both* virtual packages, is
>> /usr/bin/java. You should know the result with using that
>> alternative...
>Wrong. This is guaranteed by java-virtual-machine, not java*-runtime!
That doesn't makes it better. YOu have a package dependency, but then
youa re using *one* entry place, which basicly has no dependency
handling *at all* and does not interact with the requirements of your
package *at all*.
Both, j*-r and j-v-m are in my personal opinion completly useless.
They don't give you anything, no dependecy handling, not garatees,
that it works. Nothing.
>I don't want to put the burdon of testing all possible runtimes to
>library packagers. In most cases they can't do this even if some unit
>tests are included.
Unfortunatelly yes :( See the FindingWorkingRuntime and
ApplicationClasspath page son java.debian.net. This problem is
adressed there somewhere. But basicly the choice is between either
strict testing and dependencies and no failures on one side and less
strict testing and dependecies but failures on the other side. Maybe
we can agree on something in the middle...
>For example, I can now tell that libtomcat4-java and all its libraray
>dependencies work with Kaffe 1.1.3. This does not mean that tomcat4 uses
>all possible methods in these libraries. So IMHO it would be incorrect
>for the all of them to depends on "kaffe | java2-runtime" since that
And BTW: what will happen if you add a webapp, which require some '1.4
and not implemented in kaffe' features?
>would imply that they fully work with Kaffe. That's why the application
>that uses these libraries needs to depend on the known to be working
>JVM(s) and runtime(s).
ACK. And IMO, they should use both of these as 'one'.
>>So, I don't know how far away sarge is, but maybe instead of getting
>>yourself flamed here, put up your commets at the above page and maybe
>It's not flaming. It's just a discussion with some misunderstanding. ;-)
I know :) I've had my share of them during the proposal discussion :)
>>we get that implemented earlier than the next Debian release :)
>Don't be so pessimistic about Debian releases! :-)
I don't mind, I'm running unstable+experimental now :)
>I hope to be able to read your proposal this weekend since you obviosuly
>have addressed some of the problems that I tried so solve.
That would be great! Anyway, I will wait for the result of our 'common
packaging' discussion on java.debian.net until I take further steps.
It would be a great thing, if we (gentoo, JPackage, Debian) could
agree on a certain set of policies and tools, so that java apckaging
becomes a lot easier and also more dependend. And of course better for
our users :)
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
