> >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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
