Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >And finally, what's the effect of -classpath a.jar:b.jar supposed to
> >be? How does it alter the class lookup? What about the current
> >directory? Is that included automatically? And so on ...
>
> If we want to have policy define things that deep down, we will never
> get anything done. This interface for /usr/bin/java and /usr/bin/javac
> is not to be used in packaging. This 'interface' is simple something
> to give to the user, so that not everything is different from what he
> knows.
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 ;)
> >A lot of these are questions that you get to ask yourself when you
> >write system class loaders in a VM.
>
> But I'm not. I try to write a policy for debian.
You don't know what you're missing out on ;)
> >Then you need some authority to determine the 'best and latest version' of
> >free VMs for those people who don't want to install non-free software (a lot
> of
> >debain users, I think). I propose the creation of a
> >debian-who-s-got-the-best-free-java mailing list for bug reports about VM
> >compatibility ratings, flame wars about whose CLASSPATH is longer, and of
> >course the never-ending religious wars between kaffe and gcj zealots. No,
> >please don't do 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?
> * 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?
> * get a free one before a unfree one.
yay! I'm all for that ;)
> IMO in this order, as the first two 'make it work'. But other opinions
> my differ. Please give me a different way.
I'd leave to packagers to explicitely name those VMs that work with their
package, i.e. they built their package with the VM, and tested it, and it
worked. If the packager says it works with sablevm, then it should work with
sablevm. If the packager says it also works with kaffe, then it should also
work with kaffe. If the packager doesn't say that it works with sun's vm, then
it would be wrong to assume that it does.
I think your priority scheme tries to solve the problem what to do when two or
more VMs are able to run an application. Instead of trying to write an engine
to pick what the debian policy considers to be the best VM for the task, why
not let the packagers and the users work it out? I think that a better scheme
would honor user preferences as expressed in their $PATH setting.
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 on the PATH, which is sableVM in this case.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: