On Fri, May 26, 2006 at 05:12:51PM -0500, Tom Marble wrote: > All: > > In reviewing the proposed changes to Debian Java Policy [1] [2] > please allow me to make the following suggestions: > > 1. With respect to virtual packages [3] I understand that > Debian Policy does not allow packages in "main" to > depend on packages in "non-free". Therefore a distinction > must be made between the provides for "main" and "non-free". > > As naming can be somewhat problematic allow me to > separate the choice of names (which involves clarity, brevity > and trademark issues) from the use of names (use in control > and update-$J-alternatives) via the following variables > Here I am showing my proposed choices for names but I'm more > interested in your opinion of name usage below: > > J=cafe # the generic name of a technology that runs coffee like programs
J can be "java". As consensus of debian-legal ML its okay to use the word Java. They think its okay to use it as MJ Ray said its an island. > R=runtime # the name of the part of a platform to run such programs > D=dev # the name of the superset of $R to develop such programs > P=plugin # the optional part of $R that provides OJI plugin capability > > For packages intended for "main" control cannot have any Depends: > on "non-free" provides so a sample entry could be: > Depends: $J-$R > NOTE: a user may still run those packages in "main" with a > "non-free" $J implementation, but would have to do so manually > (update-java-alternatives) and not via dpkg dependencies AND > would be required to have a Free $J-$R installed even if it > were not used for the program in question. > > For packages in "non-free" or "contrib" the entry could be: > Depends: $J-$R | $J-$R-nonfree > In which case a $J-$R-nonfree could satisfy the dependency. > > Therefore for a given substitution of name choices I propose > the following alternative to [3] > > Free: > * $J-$R > * $J-$D > Non-Free: > * $J-$R-nonfree > * $J-$D-nonfree Why not let only free runtimes provide $J-$R/$J-$D and nonfree runtimes provide just both. Then people using software from main can be using with every runtime without fiddling with update-$J-alternatives. > 2. I have additional ideas about update-$J-alternatives (UJA) which really > should be the subject of a separate e-mail. For now let me > propose that we need a list of components (executables or plugins) > which need to be marshaled by UJA. This should be the union of > all components provided by all of: > * $J-$R > * $J-$D > * $J-$R-nonfree > * $J-$D-nonfree > > Starting with Sun Java this list of components would be: > for $R: > ControlPanel > java > java_vm > javaws > keytool > kinit > klist > ktab > orbd > pack200 > policytool > rmid > rmiregistry > servertool > tnameserv > unpack200 > for $D: > appletviewer > apt > extcheck > HtmlConverter > idlj > jar > jarsigner > javac > javadoc > javah > javap > java-rmi.cgi > jconsole > jdb > jinfo > jmap > jps > jsadebugd > jstack > jstat > jstatd > native2ascii > rmic > serialver > for plugin (NOTE: this should be generic for any plugin provider) > mozilla-javaplugin.so > firefox-javaplugin.so > mozilla-snapshot-javaplugin.so > > As a concrete example, using the name choices above, the UJA > config file for Sun Java would be (/usr/lib/jvm/.java-1.5.0-sun.jinfo): Thats fine. java-gcj-compat is handled by this already too. I'm currently working my debconf frontend to handle update-java-alternatives during runtime installation. It can even provide a nice "user-interface" after installation. More to come about this. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
