Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>The definition of what's to be expected as normal keeps changing all the time
>in the java world, as I'm trying to make clear with my questions on your
>interpretation of java's class loading semantics.
>From your point, but not from the guy starting a java app...
>> Yes, but does kaffe1.1.1 replace sablevm? Or a BD java 1.3?
>Why should it?
You should have a look at the alternative system on debian maschines.
Currently /usr/bin/java is managed via this alternative system. So the
package, which supplys the highes priority wins and gets
'/usr/bin/java'. If sablevm and kaffe are installed and I depend on
kaffe, but sablevm installs a higher priority, then I'm f****d up.
>I'd consider kaffe removing some other unrelated package from my
>system to be a serious bug.
It has nothing to do with the packaging system, but with alternatives.
man update-alternatives
>> Lets say it this way: There is such a thing as a reasonable debian
>> developer and I think that he should be able to sort that out.
>Unfortunately, I still don't get it. Do you expect VM maintainers to
>rate the compliance of their VM packages, some third party (like
>yourself), or the users after they install a VM?
Actually I don't mind at all, what the free VM package use as a
priority. What I mind are the unfree ones for teh alternatives of
/usr/bin/java-version.
If this is such aproblem, then I will change my proposal to only
specify the unfree interface priorities (basicly: release x 100).
>> Only that the three unfree ones are used via the 'unfree interface'
>> and that the packages may use whatever order it may find suitable. If
>> we find a way to factor this 'search' out into a differnt programm, it
>> may be able to set preferences.
>Great, as that's a system I could live with ;)
Yeah :)
>I wouldn't let the packager decide what VMs should be tried in which order, as
>I want to be able to set my preferences myself (and I may not want to prefer
>VMs based on their perceived compliance with JDK 1.4 APIs, for example), just
>let the packager limit the options to the VMs that are known to work with the
>package.
[...]
This could be done at a later time with a app, which will return a
installed 'java' command (java as in 'runs java byte code), based on
installed packages and known working packages and user preferences. If
you want to supply such a app, it could go into java-common and policy
could be changed, so that apps have to use it.
I hope you understand, that I have already enought work with
implementing my proposal, before I try another one :)
>> I don't mind which package it finds first, but that it *only* finds JVM,
>> which are capable of running the programm.
>what about adding a /usr/share/java/jarregistry directory with a file per java
>package that contains a
>Debian-Can-Run-On-VM: vm-a vm-b
This should be done at buildtime and not at runtime. Again, it may be
done via the above described 'findjava' script.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: