Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler...
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 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 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): :: name=java-1.5.0-sun-1.5.0.06 alias=java-1.5.0-sun priority=53 section=non-free runtime ControlPanel /usr/lib/jvm/java-1.5.0-sun/jre/bin/ControlPanel runtime java /usr/lib/jvm/java-1.5.0-sun/jre/bin/java runtime java_vm /usr/lib/jvm/java-1.5.0-sun/jre/bin/java_vm runtime javaws /usr/lib/jvm/java-1.5.0-sun/jre/bin/javaws runtime keytool /usr/lib/jvm/java-1.5.0-sun/jre/bin/keytool runtime pack200 /usr/lib/jvm/java-1.5.0-sun/jre/bin/pack200 runtime policytool /usr/lib/jvm/java-1.5.0-sun/jre/bin/policytool runtime rmid /usr/lib/jvm/java-1.5.0-sun/jre/bin/rmid runtime rmiregistry /usr/lib/jvm/java-1.5.0-sun/jre/bin/rmiregistry runtime unpack200 /usr/lib/jvm/java-1.5.0-sun/jre/bin/unpack200 dev appletviewer /usr/lib/jvm/java-1.5.0-sun/bin/appletviewer dev apt /usr/lib/jvm/java-1.5.0-sun/bin/apt dev extcheck /usr/lib/jvm/java-1.5.0-sun/bin/extcheck dev HtmlConverter /usr/lib/jvm/java-1.5.0-sun/bin/HtmlConverter dev idlj /usr/lib/jvm/java-1.5.0-sun/bin/idlj dev jar /usr/lib/jvm/java-1.5.0-sun/bin/jar dev jarsigner /usr/lib/jvm/java-1.5.0-sun/bin/jarsigner dev javac /usr/lib/jvm/java-1.5.0-sun/bin/javac dev javadoc /usr/lib/jvm/java-1.5.0-sun/bin/javadoc dev javah /usr/lib/jvm/java-1.5.0-sun/bin/javah dev javap /usr/lib/jvm/java-1.5.0-sun/bin/javap dev java-rmi.cgi /usr/lib/jvm/java-1.5.0-sun/bin/java-rmi.cgi dev jconsole /usr/lib/jvm/java-1.5.0-sun/bin/jconsole dev jdb /usr/lib/jvm/java-1.5.0-sun/bin/jdb dev jinfo /usr/lib/jvm/java-1.5.0-sun/bin/jinfo dev jmap /usr/lib/jvm/java-1.5.0-sun/bin/jmap dev jps /usr/lib/jvm/java-1.5.0-sun/bin/jps dev jsadebugd /usr/lib/jvm/java-1.5.0-sun/bin/jsadebugd dev jstack /usr/lib/jvm/java-1.5.0-sun/bin/jstack dev jstat /usr/lib/jvm/java-1.5.0-sun/bin/jstat dev jstatd /usr/lib/jvm/java-1.5.0-sun/bin/jstatd dev native2ascii /usr/lib/jvm/java-1.5.0-sun/bin/native2ascii dev rmic /usr/lib/jvm/java-1.5.0-sun/bin/rmic dev serialver /usr/lib/
Bug#367562: Please make dependency on sun-java5-demo optional
Alessandro Polverini is correct. We intend to loosen this restriction which is currently part of the README [1] in the DLJ bundle for 1.5.0_06. As soon as allowed by the license then the control file can be changed to make the demos/ and samples/ subdirectories optional. The packaging has been made separate in anticipation of this forthcoming flexibility. Regards, --Tom [1] https://jdk-distros.dev.java.net/developer.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368467: sun-java5-plugin: amd64 support
We realize that this is important as demonstrated by the fact that this is RFE# 4 for Java [4]. The original bug has the background information [1] and we now have tracking bugs in Debian [2] and the jdk-distros project [3]. What would be helpful is to document best practices for the "install 32-bit plugin in a chroot environment" even though it is a hack. Similarly helpful would be proposals on how to leverage BiArch or MultiArch to install the 32-bit client software [5] on an amd64 system. The complete fix, of course, will depend on native amd64 binaries of the client software (and corresponding browsers). Regards, --Tom [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368467 [3] https://jdk-distros.dev.java.net/issues/show_bug.cgi?id=13 [4] http://bugs.sun.com/bugdatabase/top25_rfes.do [5] client software: -client VM, Class Data Sharing, Java Web Start, and Java Plug-in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370296: DLJ only allows distributing the exact same file
Walter: I have just posted a notice to debian-legal about the availability of new DLJ FAQ [1] which further clarifies our intent. It is the intent of the DLJ that licensees such as Debian will work towards compatibility with their Operating System [2]. The sun-java5 packages have been split for very specific reasons to both comply with the DLJ and with Debian Policy. The package metadata (dpkg dependencies) have been designed so that as installed on Debian the DLJ will be fulfilled: - sun-java5-jre contains architecture independent files - sun-java5-bin contains architecture dependent files and has circular depends on sun-java5-jre - sun-java5-plugin is *optional* integration for web browsers because server oriented systems cannot have a Depends: on browsers - sun-java5-jdk contains the Java Development Kit (JDK(TM)) - sun-java5-demo contains the demonstration and sample files with the JDK. There is a circular depends on sun-java5-jdk because the demo files are required by the license when the JDK is installed. Separating these demo files into a separate package can be converted to Suggests: as soon as allowed by the license. - sun-java5-source package installs the src.zip file which explicitly listed as optional in the README - sun-java5-fonts package integrates Lucida fonts (from the JRE) using defoma and it is optional because defoma integration is not mandated by the license and if users already have a Lucida font package installed with defoma then this integration is redundant. - sun-java5-doc package facilitates integration of the Sun JDK Documentation and has no relationship to the DLJ bundles in question -- it has been provided as a convenience to developers who download Javadocs from the http://java.sun.com website. What's more, further clarification on modifications is planned for the README [3]. Reaching this technical and legal solution is what I am most proud of in the work on these packages -- it is proof that the spirit of the DLJ of enabling distros to "do the right thing" is the best way to get the Sun Java platform on distros not directly supported by Sun. Regards, --Tom [1] https://jdk-distros.dev.java.net/developer.html [2] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q26 [3] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q9 signature.asc Description: OpenPGP digital signature
Bug#370295: DLJ prevents running jython with sun-java
Walter: I have just posted a notice to debian-legal about the availability of new DLJ FAQ [1] which further clarifies our intent. It is not the intent of the DLJ to prevent running Jython. Please see the new FAQ #13 #14 and #15 [2]. If Sun wanted to discourage innovations like Jython and JRuby we would not leave web content on our official web sites that referred to them [3]. A further demonstration that prohibiting Jython is not our intent is through an award at JavaOne 2006 for the Java Model Railroad Interface (JMRI) which includes Jython [4]. Indeed the governance organization that guides the evolution of Java Platform(TM), the JCP [5], has specifically endorsed this entire *class* of innovations by adding a supporting bytecode, invokedynamic, to the Java programming language [6]. You may close this bug without making Jython conflict with sun-java. Regards, --Tom [1] https://jdk-distros.dev.java.net/developer.html [2] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q13 [3] http://java.sun.com/developer/technicalArticles/JavaLP/groovy/index.html [4] http://java.sun.com/javaone/sf/dukes_choice_awards.jsp [5] http://www.jcp.org/ [6] http://www.jcp.org/en/jsr/detail?id=292 signature.asc Description: OpenPGP digital signature
Bug#370245: Export control problems in license
Walter: I have just posted a notice to debian-legal about the availability of new DLJ FAQ [1] which further clarifies our intent. Please see the new FAQ#30 [2]. HTH, --Tom [1] https://jdk-distros.dev.java.net/developer.html [2] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q30 signature.asc Description: OpenPGP digital signature
Bug#376888: sun-java5-bin: README.alternatives includes wrong syntax to
Florian Laws wrote: > the call to update-java-alternatives as documented in > /usr/share/doc/sun-java5-bin/README.alternatives seems to be wrong. > > I think it should read > update-java-alternatives -s java-1.5.0-sun > instead of just > update-java-alternatives sun-java5 You are right! I have fixed this in SVN [1] and it will be resolved in the next upload. Thanks, --Tom [1] https://jdk-distros.dev.java.net/source/browse/jdk-distros/trunk/linux/ubuntu/sun-java5/debian/README.alternatives.in?rev=161&view=text -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370296: Bug#369950: eclipse could is not search in the right place for sun-java5-jdk
All:
Please note that
1. The Eclipse packaging predates the recent changes
in java-common (>= 0.25) which is part of a broader
Debian Java Policy initiative to harmonize
access to multiple implementations [1].
At some point the Eclipse packaging should simply
start with /usr/bin/java (assuming there is at a least
one implementation available as determined by
adding Depends: java-runtime ).
2. The following fix to the current eclipse packaging has been
tested and works (if *no other implementations are
installed*):
[EMAIL PROTECTED] 13% diff -Naur
eclipse-3.1.2{-pristine,}/debian/extra/java_home
--- eclipse-3.1.2-pristine/debian/extra/java_home 2006-07-07
19:46:33.0 -0500
+++ eclipse-3.1.2/debian/extra/java_home2006-07-09 16:23:16.0
-0500
@@ -4,6 +4,7 @@
/usr/lib/jvm/java-gcj
/usr/lib/kaffe/pthreads
+/usr/lib/jvm/java-1.5.0-sun
/usr/lib/j2se/1.5
/usr/lib/j2se/1.4
/usr/lib/j2sdk1.5-ibm
[EMAIL PROTECTED] 14%
3. Note if one of the two implementations is installed on
the system which precede Sun Java (in java_home above)
then Eclipse will start with the first one it finds.
In that case the work around is to add the following
to ~/.eclipse/eclipserc
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
4. Even in the case listed in #3 Sun Java can still be used
to edit and run Java programs by doing the following:
a. open the Window | Preferences dialog
b. Expand the tree > Java > Editor > Installed JREs
c. click Add...
select the /usr/lib/jvm/java-1.5.0-sun directory
Allow my to respectfully propose the patch in #2 be applied
to the current Eclipse packaging to close this bug.
Then, separately, as Debian Java Policy evolves the Eclipse
packaging should be updated to take those conventions
into account.
Regards,
--Tom
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365408
http://wiki.debian.org/Java/Draft
P.S. Please note, also, that I have just updated the documentation
for installing the Sun JRE on Debian:
https://jdk-distros.dev.java.net/debian.html
as well as installing the Sun JDK on Debian:
https://jdk-distros.dev.java.net/debian-dev.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375745: sun-java5: [INTL:sv] Swedish debconf templates translation
Daniel Nylander wrote: > Here is the Swedish translation of the debconf template for sun-java5. Thank you very much for this translation! I have included it in SVN [1] and it will get included in the next upload. Regards, --Tom [1] https://jdk-distros.dev.java.net/source/browse/jdk-distros/trunk/linux/ubuntu/sun-java5/debian/po/sv.po?rev=162&view=markup -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369950: eclipse could is not search in the right place for sun-java5-jdk
(sorry, sent previously to the wrong bug number :-( )
All:
Please note that
1. The Eclipse packaging predates the recent changes
in java-common (>= 0.25) which is part of a broader
Debian Java Policy initiative to harmonize
access to multiple implementations [1].
At some point the Eclipse packaging should simply
start with /usr/bin/java (assuming there is at a least
one implementation available as determined by
adding Depends: java-runtime ).
2. The following fix to the current eclipse packaging has been
tested and works (if *no other implementations are
installed*):
[EMAIL PROTECTED] 13% diff -Naur
eclipse-3.1.2{-pristine,}/debian/extra/java_home
--- eclipse-3.1.2-pristine/debian/extra/java_home 2006-07-07
19:46:33.0 -0500
+++ eclipse-3.1.2/debian/extra/java_home2006-07-09 16:23:16.0
-0500
@@ -4,6 +4,7 @@
/usr/lib/jvm/java-gcj
/usr/lib/kaffe/pthreads
+/usr/lib/jvm/java-1.5.0-sun
/usr/lib/j2se/1.5
/usr/lib/j2se/1.4
/usr/lib/j2sdk1.5-ibm
[EMAIL PROTECTED] 14%
3. Note if one of the two implementations is installed on
the system which precede Sun Java (in java_home above)
then Eclipse will start with the first one it finds.
In that case the work around is to add the following
to ~/.eclipse/eclipserc
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
4. Even in the case listed in #3 Sun Java can still be used
to edit and run Java programs by doing the following:
a. open the Window | Preferences dialog
b. Expand the tree > Java > Editor > Installed JREs
c. click Add...
select the /usr/lib/jvm/java-1.5.0-sun directory
Allow my to respectfully propose the patch in #2 be applied
to the current Eclipse packaging to close this bug.
Then, separately, as Debian Java Policy evolves the Eclipse
packaging should be updated to take those conventions
into account.
Regards,
--Tom
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365408
http://wiki.debian.org/Java/Draft
P.S. Please note, also, that I have just updated the documentation
for installing the Sun JRE on Debian:
https://jdk-distros.dev.java.net/debian.html
as well as installing the Sun JDK on Debian:
https://jdk-distros.dev.java.net/debian-dev.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370295: DLJ prevents running jython with sun-java
Walter Landry wrote:
> [...]
> All of the examples given above are good, but libgetenv-java is about
> as clear as you can get. It only depends on java2-runtime and libc,
> and it serves as a replacement for java.lang.System.getenv. It
> creates a hybrid implementation.
>
> If you want to argue that it is the other packages fault, go ahead.
> That would make the java2-runtime virtual package much less useful, in
> which case there should be a java2-runtime-free virtual package.
Obviously making sun-java5 not provide java2-runtime (or whatever
provides Debian Java Policy settles upon) defeats the purpose
of packaging Sun Java.
I appreciate your trying to address an entire class of problems, but
in the case of libgetenv-java it appears that the jar is malformed.
We're it formed correctly it would be in it's own namespace.
The README.Debian says:
libgetenv-java for Debian
-
To use libgetenv-java in an application, make sure your classpath includes
/usr/share/java/libgetenv-java.jar and LD_LIBRARY_PATH includes /usr/lib/jni
-- Mark Howard <[EMAIL PROTECTED]>, Fri, 27 Jun 2003 15:50:01 +0100
Inspection of the jar file in the aforementioned package
shows:
=== /usr/share/java/libgetenv-java.jar ===
0 Tue Oct 25 05:09:28 CDT 2005 META-INF/
48 Tue Oct 25 05:09:28 CDT 2005 META-INF/MANIFEST.MF
376 Tue Oct 25 05:09:28 CDT 2005 uk/co/tigress/System.class
[EMAIL PROTECTED] 148% jar xf /usr/share/java/libgetenv-java.jar
[EMAIL PROTECTED] 151% cd uk/co/tigress/
/tmp/uk/co/tigress
[EMAIL PROTECTED] 155% javap System
Compiled from "System.java"
public class System extends java.lang.Object{
public static native java.lang.String getenv(java.lang.String);
}
[EMAIL PROTECTED] 156%
So IN THIS CASE... it appears that the jar file is malformed
because I cannot even compile a Java program to use this alternative class
by using "import uk.co.tigress.System;" (see attached altenv.java).
This would appear to because the source file did not specify that
it was in the "package uk.co.tigress;".
[EMAIL PROTECTED] 212% javac -cp .:/usr/share/java/libgetenv-java.jar
altenv.java
altenv.java:3: cannot access uk.co.tigress.System
bad class file: /usr/share/java/libgetenv-java.jar(uk/co/tigress/System.class)
class file contains wrong class: System
Please remove or make sure it appears in the correct subdirectory of the
classpath.
import uk.co.tigress.System;
^
1 error
[EMAIL PROTECTED] 213%
So I can't even get this package to work, let alone provide an
example of how it would be a problem with the DLJ.
Please advise,
--Tom
// altenv.java
import uk.co.tigress.System;
public class altenv {
public static void main(String[] args) {
if (args.length != 0) {
System.out.println("usage: java sunenv");
} else {
try {
String env1 = "HOME";
String val1 = System.getenv(env1);
System.out.println("env " + env1 + " = " + val1);
String env2 = "PATH";
String val2 = System.getenv(env2);
System.out.println("env " + env2 + " = " + val2);
} catch (Exception e) {
System.out.println("unable to get environment variables");
System.out.println("Exception: " + e);
}
}
}
}
Bug#393153: sun-java5-jdk: please package 1.5.0-09
Albert (et al): Thank you for your interest in 1.5.0_09. This issue is also captured in an upstream bug [1]. It turns out that the _09 release has been especially delicate. Nevertheless I expect to push out the DLJ bundles for _09 in the next day or so -- within our goal of a 1-week delay from the BCL (classic) bundles. I will let you know when the DLJ bundles are ready for Debian packaging. Regards, --Tom [1] https://jdk-distros.dev.java.net/issues/show_bug.cgi?id=17 _ [EMAIL PROTECTED] Senior Java Performance Engineer Sun Microsystems, Inc. http://blogs.sun.com/tmarbleWhat do you want from Java Libre? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
