Re: findjava requirement (was: 4. RfD for a new debian java policy)
> >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'.
Hmm? By "alternative system' I'm talking about packages using
update-alternatives in thier postinst scripts, etc.
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.
> 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.
It could just as easily be done using a /usr/bin/java alternative.
This would also have the advantages of:
- The standard command-line java interpreter /usr/bin/java calls this
same default JVM;
- The sysadmin gets a decent setting without having to do anything
(i.e., they get the installed JVM with the highest ranking). 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.
> 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).
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.
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.
Btw, calling the script 'findjava' but the config files 'javafind' will
IMHO only add to the confusion. I'd pick one or the other.
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'd even go so far as to
say that each java app's man page should contain a link to this
documentation (which is also in man format, since this is what policy
requires every app to provide).
Ben.
Reply to: