[lsb-discuss] LSB conf call notes for 2008-02-13
Wichmann, Mats D
mats.d.wichmann at intel.com
Wed Feb 13 16:41:44 PST 2008
> OK, pretty straight forward. First to deal with the multiple JVMs, we
> just use the Debian update-alternatives system.
Unless this system is substantially modified from how
I understand it to work now, this isn't going to work
If an application is installed which requires lsb-java,
then when it is invoked it must make sure it's executed
by the correct one of possibly many java interpreters.
The alternatives system allows for /usr/bin/java to
pass the reference on to the java that was most recently
configured to be the default, and worse, it's quite possible
for it to be something different than what the package
detected when it was installing (invalidating whatever
install-time checks might have been done to make sure things
were safe). update-alternatives is an administrative task;
you have to be root to run it, so the application has no
chance to select the correct java at runtime.
So this system actually makes prospects far worse,
because it reduces the predictability of behavior.
Now if the alternatives system had a user-level component,
and perhaps one that operated at runtime, somewhat
parallel to how the #! mechanism works now, such that
an application could indicate at startup that it needs
a particular java (by a generic name rather than by
a filesystem path, which would likely differ across systems),
then it might have some prospects.
More information about the lsb-discuss