Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler...
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/
Reply to: