Re: findjava requirement (was: 4. RfD for a new debian java policy)
Hallo Ben,
* Ben Burton wrote:
>Well, IMO the alternative system exists so that users don't need to
>learn how each different package works around it in its own different
>way. Instead it provides a standard system for setting system-wide
>defaults.
So we understand something differen when we talk about the
'alternative system' :). IMO your usecase would be called 'default
system'.
>> It's supported, but I don'T think that should be the default.
>> findjava does the following now:
>> * look into env for a JAVA_OVERWRITE_VM
>> * source the $HOME/.findjavarc and look into env for JAVA_OVERWRITE_VM
>> * put the user pref java package first into teh serach path
>> * search the searchpath for a working VM
>> * first with 'OPTION' (server and client just now)
>> * just teh first available
>There are two different user settings we were discussing:
>1) Specify a JVM for this specific run, to be used regardless of whether
>it's in the list of known working JVMs. This is $JAVA_OVERWRITE_VM as I
>understand from your description.
>2) Have a system-wide "default JVM" that is always used when it is in
>the list of known working JVMs. This is what I was proposing we use
>the alternative /usr/bin/java for. Is this currently supported by
>findjava?
Currently the second thing isn't implemented. I coud be easily done by
sourceing a /etc/javafind file before the $HOME/.javafind file, both
with the same content. system wide setings would be overwritten by
user wide. For your usecase, dopn't use the $JAVA_OVERWRITE_VM but the
the $PREFERRED_VM_PACKAGE_NAME Variable. Not that the first is a
something like '/usr/bin/something -server' and the last is a package
name!
>This system-wide default allows a sysadmin to say "use gij as the
>default JVM unless it's not known to work, in which case use one of the
>ones that the packager suggests". And of course it allows users to
>override the sysadmin's decision through $JAVA_OVERWRITE_VM.
Jain: $JAVA_OVERWRITE_VM is IMO for the case that you package is not
installed in this system. Thats why it is a path to the binary and not
a package name. Take it as given that the above /etc/... is also
implemented, then the lookup would be like this:
* Look into the env for $JAVA_OVERWRITE_VM (making sure that the
comand exist).
- source /etc... and $HOME/...
* look into env for $JAVA_OVERWRITE_VM (user overwrites system wide
setting)
- put the $PREFERRED_VM_PACKAGE_NAME first in the searchpath if it is
in the list of know working VMs. Again, system wide settings are
overwritien by userwide due to the order in which the fiels are
source'd
*This is where the 'normal' things start*. Overwrite is *not* the
normal case.
* Search the list for a installed VM, which includes the given
--option. Output the first found.
* search the list for installed VM, output the first found.
* issue a error message and exit 1.
>This is precisely what would have happened in the for loop we were
>arguing about, FWIW.
I don't argue about your loop. I would do the same and everybody lese
would do so too. So it should be refactored, so that it behaves the
same everywhere and that bugs are in one place and not all over.
I'm argueing against using the alternative system for what *I* think
it wasn't made for
>> The 'findjava' algo was described in one of my mail.
>Hmm, I remember seeing it but I don't remember anyone suggesting that it
>be made compulsory.
Dalibor argued quire havily for it :)
>There have been a lot of emails in this thread most
>of which have identical topics. :) Anyway, we're discussing it now. :)
:)
BTW, the last open topic I still have is 'include' and
'include/something'. How should that dealted with? Put everything into
one dir, as IBM does and patch around? Use a java-config setting?
>Okay, I'll take a look now at the scripts you've uploaded.
Thanks!
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: