Hello Ean, Thursday, October 9, 2003, 7:33:22 AM, you wrote: > For instance, if the Tomcat maintainer decides that compiling certain > baseline classes with GCJ before running the main system with GIJ is a > good idea then I can't see that findjava will elegantly accomodate that. > The idea itself may be sound but probably doesn't belong in a common > package and actually probably belongs in something like > tomcat-gcj-booster.deb or somesuch.
True. And this package will depend *only' on gcj and will not touch any java related things like jar files or java bytecode interpreeter. This things will be handled --more or less-- under normal debian policy. > All things considered, I think that my preference is to have each VM > provide some Debian-specific tightened up version of $JAVA_HOME that we > specify in java-policy and then have $JAVA_HOME be managed by > alternatives. IMO: JAVA_HOME is good for three things: * ant, which depends on the java property java.home set and some apps in java.home/bin/* * other apps, which rely on internal things in java.home * uses '$JAVA_HOME/bin/java to start the app The first is done in the 'ant-environment', which specifies a 'kind of' java.home, but the only requirement is 'it runs ant'. The second can't properly be helped in any other way than 'Depends: <only sun dereived JVMs>' The third can be trivaly helped by patching the startup script, which would probably anyway be needed bvecause of 'free VMs', which are surely not considered (think: internal options) in this startscripts. Did I miss something? Anyway, even if we specify a 'JAVA_HOME' layout, it will not help us with the alternative system. The problem with alternactives are quite different from why a JAVA_HOME layout would be usefull or not. No matter we are using '/usr/bin/java' or '/usr/lib/java-home[/bin/java]', the same problems will show up. We would then need a 'findjavahome' script. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
