Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> '/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 think we both agree that this scheme is not a good solution for java
> >on debian. It doesn't give users the necessary flexibilty to deal with
> >ever changing definition of what should be considered as normal in
> >java. For example I can't really make sure that I run ant 1.5.3 with
> >Sun's JDK 1.4.1 because I need the javah task to work, but
>
> You can never make this sure beforehand. This are bugs, which show up
> and you simple get the fix and be done with it.
Don't you see that your interface definition attempt is contradicted by this?
It is not flexible enough to deal with such cases, because it assumes there
will be no compatibility problems between different point releases of a
particual java API release, like java 1.4.1 and 1.4.2. That is simply not true,
and calling it bugs, and referring to getting a fix, fails to realize that
there is a compatibility problem, not just a bug. If ant relies on internal
classes from Sun (and we both know it does) it can break with every small
change Sun makes to their internals, and there is no way to guarantee that
won't happen, whether you define an interface or not, because it circumvents
the interface.
> IMO you can't make java save *in all cases*, as long as you don't
> depend on one specific version of one JVM. But then we have just
> 'removed' the main thing why java was created.
But don't you see that that's already the case with any application that messes
with internals of Sun's implementation? Such applications are tied to a
specific VM implementation and version by design, and will keep breaking with
new releases from Sun. Your idea that Sun doesn't break things with minor
upgrades of their VM is wrong. Codifying it as a debian policy won't make it
true, as Sun doesn't care about Debian.
> >> It has nothing to do with the packaging system, but with alternatives.
> >> man update-alternatives
> >update-alternatives is useless for non-root users. See for example this
> >session:
> [non root session]
> >hooray for update-alternatives being helpful ;)
>
> Thats why only the unfree interface is maintained with it. For the
> rest, you are very welcome to write your implementaion of
> 'findworkingjava', which will accept a per user configuration file.
If we agree that having such a mechanism is a good thing, then it would be nice
to have a common understanding of what we want, what we need and how we get
there. I guess we shall start a new thread for this issue, if you think it
makes sense to have it in a new policy.
> >> If this is such aproblem, then I will change my proposal to only
> >> specify the unfree interface priorities (basicly: release x 100).
> >Stupid question: what's a release? What priority value should be given
> >to J2SE v 1.4.2_01 ? 142? 142.01? 14201?
>
> major.minor.release.build
> (majorx1000)+(minorx100)+(releasex10)+build
>
> Happier?
Yes, thanks, since it's a much clearer specification. The clearer your policy
proposal gets, the easier it will be to apply by packagers.
> >I think that such an app would help solve the current problems with
> >picking the 'right' java executable for the job in a more general
> >fashion than what we have now (weird and useless /usr/bin/java
> >interface with even weirder alternatives scheme) or your proposal,
> >which seems to try to band-aid debian to limp along with the non-free
> >VMs by introducing a non-free interface with another weird rating
> >system.
>
> Note that this programm still has to sort out, what 'java' is *able* to
> run it. The app may add some classpath jars as well, depending on
> which java is used. I don'T think that could be done with a
> /usr/bin/java, which uses then one other 'java' to run the app.
I'm not talking about an "command line options emulation interface" here (like
your original interface proposal), just about a way to delegate the call as it
is made to the java executable to another java executable given some knowledge
about which java executables work with the program, and a set of user
preferences.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: