Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>Why do you assume familiarity with some command line synopsis? The effect of
>-classpath a.jar:b.jar for example can have different effects depending on the
>VM used, and its version. That's what the documentation is good for ;)
>From my limited java experience, it will not matter. For example the
jikes delegate of the ant javac task uses only the classpath but the
javac task includes a 'bootclasspath' option. -> jikes will be called
with 'bootclaspath jars' + 'classpath'. There is always a workaround,
which will work 'good enough'.
For the sepcial cases, there are always Conflicts: and bugreports.
>> But I'm not. I try to write a policy for debian.
>You don't know what you're missing out on ;)
Based on this discussion, I think that I'm happy with that...
>> Just setting them all to 200 isn't any better. This priority system
>> should IMO fullfill this goals:
>> * get a newer version before the older one
>uh, that's what the debian packaging system does already, right? when
>let's say kaffe 1.1.1 is out, it replaces kaffe 1.1.0 in debian,
>doesn't it?
Yes, but does kaffe1.1.1 replace sablevm? Or a BD java 1.3?
>> * get a more spec complient version before any not so spec complient
>> version.
>that's the ugly part, where someone gets to be the judge who's how much
>compliant. It's not clear how you want to judge spec compliance. Could you
>elaborate on that?
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.
>> * get a free one before a unfree one.
>yay! I'm all for that ;)
I'm even more happy seeing you happy :)
>I think your priority scheme tries to solve the problem what to do when two or
>more VMs are able to run an application.
>From a packages POV, they wont access the priority system. Only the
unfree interface (and /usr/bin/java, but that shouldn't be accessed by
debian packages) is controled by this priorities and there only the
'greater release gets greater prority' rule applys.
>Let's hypothetically say the user tries to run tomcat-xyz, which is
>according to the packager able to run on both sun's VM, blackdown,
>IBM, and sablevm. The user prefers to run free VMs over unfree ones if
>any possible (not so uncommon for debian users), so his $PATH has
>sableVMs java executable before the unfree ones. Ideally, debian java
>wrapper will delegate the call to the first suitable VM package it
>finds
Hey, thats exactly what I wanted to do with my proposal.
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.
>on the PATH which is sableVM in this case.
I don't mind which package it finds first, but that it *only* finds JVM,
which are capable of running the programm.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: