Hallo Ben,
* Ben Burton wrote:
>> So we understand something differen when we talk about the
>> 'alternative system' :). IMO your usecase would be called 'default
>> system'.
>Hmm? By "alternative system' I'm talking about packages using
>update-alternatives in thier postinst scripts, etc.
me too :)
>In this case we're talking about setting a system-wide default from
>amongst a series of installed options, which is precisely what the
>alternatives system does.
IMO the 'alternative system' is not used for this. Looking what
alternatives are installed in my system, they are either
* editors or other interactive things (telnet, www-browser)
* different version of the same tool (autoconf, gcc, shells)
* apps which do not require commandline apps (x-session-manager)
* things which behave the same (x-cursor-theme, awk)
The rest is more or less java related tools, which do not fit the
above, as this discussion has showed.
/usr/bin/java is not interactive, not a different version of the same
tool (/usr/bin/java-1.4 would be, but even that was not enough), does
need commandline options and behaves not exactly the same as the next
alternative.
And in all cases (I think) it is used 'as is' and without following
the symlinks. Using checks whether the alternative is possible, is IMO
contradicting the whole alternative system.
> - The standard command-line java interpreter /usr/bin/java calls this
> same default JVM;
The standard JVM should not be used in any package and if it wouldn't cause
even more problems, I would remove it altogether.
/usr/bin/java* is only for Hello World.
> - The sysadmin gets a decent setting without having to do anything
> (i.e., they get the installed JVM with the highest ranking)
Bad ide: who should get the highest ranking? I got persuaded that this
would only lead into a lot of flamewars...
> With the /etc/javafind proposal, you'd either ship with no default
> at all or you'd ship with a default that might not be installed on
> the system.
No. The app becomes the most useable installed VM: The findjava script
will always return a valid JVM. It will return the first available in
the searchlist, so the maintainer of the list can make some nice
preferences. Only if the sysadmin or user want to change this, he has
to change a file.
>> Jain: $JAVA_OVERWRITE_VM is IMO for the case that you package is not
>> installed in this system.
>Or if the packager prioritised JVM x but I really want to run this
>particular app with JVM y (which occurs later in the search path).
^^^^^^^^^^^^
No, for that case there is 'PREFERED_VM_PACKAGE_NAME', which will
place your beloved VM first in the search path. *If* it is a possible
VM.
>Anyway, seeing as you're already using local .javafind config files, I
>guess I'm happy with /etc/javafind for the system config. Though I most
>definitely do *not* think we should encourage users to set
>JAVA_OVERWRITE_VM in these config files - this is dangerous since it
>overrides the packagers' lists of known working JVMs in every case.
Yes, and I will state so, when I write the docs for the apps. This is
only good for two cases:
* Test a VM
* Use a VM outside of the packageing system
The last should become more unusual, if we get mpkg-j2sdk into debian
and mentioned in the java FAQ.
>I'd in fact suggest that we don't allow JAVA_OVERWRITE_VM in the config
>files - just the safer PREFERRED_VM or whatever it was - and only allow
>JAVA_OVERWRITE_VM in the environment, so that it's used on a
>case-by-case basis.
IMO it can be nice to have it. I would like to be able to test more
than one package, if I install a new (unfree) VM and would be slighly
fed up to type it in every xterm I open. It doesn't really matter if
I have to add this to .bash_profile or .findjavarc...
See the implementation.
I wouldn't mind omitting it in the 'example' file, which should IMO be
copied into $HOME.
>Btw, calling the script 'findjava' but the config files 'javafind' will
>IMHO only add to the confusion. I'd pick one or the other.
Sorry, misnamed only in the mail. They are properly named in the
script.
>Anyway, I still have to read through findjava and related scripts. Btw,
>the user configuration (e.g., the environment variables and config
>files) will need to be very well documented, and furthermore documented
>somewhere that users will easily find them.
I will add manpages for findjava, findjavarc, java-config (and
CLASSPATH?), and update-java-config.
>I'd even go so far as to say that each java app's man page should
>contain a link to this documentation
As they use the findjava script they should.
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
