> You mean something like > > |You must depend on all working java virtual maschines and search all > |this packages for the java virtual maschine binary.
Yes. > I thought that this was fairly obvious... I mean, it's pretty stupit > if not :) There are lots of things in debian policy that are either obvious or common-sense. It certainly can't hurt to include it. > >Note that this is going to get messy for packagers - the packager of > >each java app or library will presumably need to test this app on all > >JVMs with each new release, and will also need to be aware of when each > >JVM makes a new release of its own so they can test their app with the > >new JVM version. > > I hope that this won't be the case. Anyway, we had such a situation > with for example flex and so I think thatc an be 'managed' with simple > bugreports. I'm not really comfortable with the idea of "don't test, just assume it works until someone tells you otherwise". Yes, it happened with flex but that was a once-off. With this java proposal it will become institutionalised. > >I would make this clearer. I presume you mean that "when searching > >for a known working JVM, non-free JVMs should be included in this search > >list". However, the text could well be misinterpreted as "the non-free > >JVMs should be used wherever possible, before searching for free JVMs". > > How about > -- > As "unfree" virtual maschines of a certain version almost > certainly will run code developed for this version, the "unfree" > interfaces for that version should be included in this search list. > The order, in which this list is searched is up to the package > maintainer. > -- Works for me. > Most users will anyway only install one version of a virtual maschine. This I find unlikely, especially if packages are explicitly depending on known-working JVMs. The more java packages I have installed, the more likely it is that dependencies require me to have a variety of different JVMs on my system. Ben. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
