Bug#285303: java-common: Typo in JAVA policy
Package: java-common
Version: 0.22
Severity: normal
Hello Debian Java maintainers,
I found several typos in the Java policy. The corrections have to
be taken with a grain of salt since I am not a native speaker and
I know next to nothing about JAVA.
This is a diff of the text version with ^^^^ to mark changed words, so
you have some contexts.
For some unknown reason, I have changed 'classpath' to 'CLASSPATH'.
Revert it if it does not make sense.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--- java.old Sun Dec 12 13:21:25 2004
+++ java Sun Dec 12 13:21:20 2004
@@ -38,9 +38,9 @@
emacsen-common for instance. As far as I know, the only
subpolicy for a programming language, is that of Perl.
- Feel free to report comments, suggestions and/or disagrements
+ Feel free to report comments, suggestions and/or disagreements
^^^^^^^^^^^^^
to the java-common package (<java-common@packages.debian.org>)
- or the Debian Java mailinglist <debian-java@lists.debian.org>.
+ or the Debian Java mailing list <debian-java@lists.debian.org>.
^^^^^^^^^^^^
Change requests should be sent as a bug to the java-common
package.
_________________________________________________________
@@ -107,7 +107,7 @@
Java compilers must provide java-compiler and/or
java2-compiler and depend on java-common. They must also
- depend on the needed runtime environemnt (java1-runtime and/or
+ depend on the needed runtime environment (java1-runtime and/or
^^^^^^^^^^^
java2-runtime).
They should use /etc/alternatives for the name 'javac' if they
@@ -126,7 +126,7 @@
(for instance a manual page per executable, see Policy 13.1).
If they have their own auxiliary classes, they must be in a
- jar file in /usr/share/java. The name of the jar should folow
+ jar file in /usr/share/java. The name of the jar should follow
^^^^^^
the same naming conventions as for libraries.
Programs must depend on java-virtual-machine and the needed
@@ -144,13 +144,13 @@
Java libraries packages must be named libXXX[version]-java
(without the brackets), where the version part is optional and
should only contain the necessary part. The version part
- should only be used to avoid naming colisions. The XXX part is
+ should only be used to avoid naming collisions. The XXX part is
^^^^^^^^^^
the actual package name used in the text below.
Their classes must be in jar archive(s) in the directory
/usr/share/java, with the name
packagename[-extraname]-fullversion.jar. The extraname is
- optional and used internaly within the package to separate the
+ optional and used internally within the package to separate the
^^^^^^^^^^
different jars provided by the package. The fullversion is the
version of that jar file. In some cases that is not the same
as the package version.
@@ -167,7 +167,7 @@
developers should know what to add to their wrappers.
This applies only to libraries, not to the core classes
- provied by a the runtime environment.
+ provided by a the runtime environment.
^^^^^^^^
Some Java libraries rely on code written in a "native"
language, such as JNI (Java Native Interface) code. This
@@ -201,7 +201,7 @@
guavac, gcj and jikes, it cannot go to main. If your
package itself is free, it must go to contrib.
* If your binary package can run only with non-free virtual
- machines (classpath has a list of free versions), it
+ machines (CLASSPATH has a list of free versions), it
^^^^^^^^^
cannot go to main. If your package itself is free, it must
go to contrib.
_________________________________________________________
@@ -211,7 +211,7 @@
The following points are discussions about the policy, either
because they have to be studied more, or are controversial.
- * Name and existance of the repository. It was removed in
+ * Name and existence of the repository. It was removed in
^^^^^^^^^
the latest version.
* The symbolic links in /usr/share/java be made by a script
instead, similar to the c-libraries.
@@ -225,11 +225,11 @@
It should exist some tool to parse this. How should it
work?
Should the tool also be used to create the necessary
- symbilic links needed by servlets under tomcat?
+ symbolic links needed by servlets under tomcat?
^^^^^^^^
- * Should there be a default classpath, similar to a
+ * Should there be a default CLASSPATH, similar to a
^^^^^^^^^
repository? Which jars should be included in that? A
standard and one optional part? If there are a default
- classpath (in the wrapper) how should it be overridden?
+ CLASSPATH (in the wrapper) how should it be overridden?
^^^^^^^^^
* How to check for a good enough jvm, and to select a proper
one to use. Are /etc/alternatives not good enough?
* Should the jvm internal classes be possible to override
Reply to: