Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
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.
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.
>> 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 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?
>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.
>Of course, only if the underlying problem is to find the 'right' java
>executable, which is how I parsed the discussion so far.
Yes, that's the main problem.
>> This should be done at buildtime and not at runtime. Again, it may be
>> done via the above described 'findjava' script.
>I beg to disagree. I want to be able to change my preferences at runtime,
>instead of having to rely on a packager to get it right when he packages the
>application.
Somewhere else you said, that it is ok for you if the packagers only
uses one dependency (which implys, that only one java binary can be
used).
If you want that this badly, please write the code.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: