FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 03-23-2010, 08:26 AM
Niels Thykier
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Hi

I have compiled two patches against the current policy that I intend to
apply Friday assuming there are no objections.

p1_trival_changes.patch is a minor fix-up that will remove a duplicate
clause and highlight some "policy" words (should, must etc) in addition
to adding me to the author list.

p2_fosdom06.patch is an adaption of the FOSDEM 06 draft[1]. The most
apparent difference is that I have not included the "Java virtual
machines" and "virtual packages" parts.
The "virtual packages" is excluded due to #365408. The exclusion of
"Java virtual machines" is because I have no knowledge of packaging JVMs
and did not know if this was a feasible request. If you believe this
should be added to the policy, please file a bug against java-common and
I will add it in a later patch provided it is supported by the team.

Applying these patches will close #505166 (p1) and#227587 (p2);
furthermore I intend to tag #365408 as wontfix based on the feedback given.

Please note that these patches will not bring the policy completely in
line with how we do things now. They are intended to reduce the
difference without being too large.
Some of you may remember my last attempt to update the policy. I have
not forgotten these changes, but the changes were done in a single large
patch, which made it hard to review. I will convert the relevant changes
from it into smaller patches.

~Niels

[1] http://wiki.debian.org/Java/Draft
 
Old 03-23-2010, 08:35 AM
Niels Thykier
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Niels Thykier wrote:
> Hi
>
> I have compiled two patches against the current policy that I intend to
> apply Friday assuming there are no objections.
>
> p1_trival_changes.patch is a minor fix-up that will remove a duplicate
> clause and highlight some "policy" words (should, must etc) in addition
> to adding me to the author list.
>
> p2_fosdom06.patch is an adaption of the FOSDEM 06 draft[1]. The most
> apparent difference is that I have not included the "Java virtual
> machines" and "virtual packages" parts.
> The "virtual packages" is excluded due to #365408. The exclusion of
> "Java virtual machines" is because I have no knowledge of packaging JVMs
> and did not know if this was a feasible request. If you believe this
> should be added to the policy, please file a bug against java-common and
> I will add it in a later patch provided it is supported by the team.
>
> Applying these patches will close #505166 (p1) and#227587 (p2);
> furthermore I intend to tag #365408 as wontfix based on the feedback given.
>
> Please note that these patches will not bring the policy completely in
> line with how we do things now. They are intended to reduce the
> difference without being too large.
> Some of you may remember my last attempt to update the policy. I have
> not forgotten these changes, but the changes were done in a single large
> patch, which made it hard to review. I will convert the relevant changes
> from it into smaller patches.
>
> ~Niels
>
> [1] http://wiki.debian.org/Java/Draft
>

Hi

I noticed I accidentally attached the slightly updated FOSDEM patch.
Attached is the correct version as well as the interdiff between the
outdated and this patch.

Sorry for the noise.

~Niels
diff -u policy.xml policy.xml
--- policy.xml 2010-03-22 21:42:34.535497348 +0100
+++ policy.xml 2010-03-23 00:30:01.775497022 +0100
@@ -327,8 +327,8 @@
<para>
Packages &mustnot; ship gcj-code without the permission of
the Java team (<email>debian-java@lists.debian.org</email>).
- Source packages that shipped gcj-packages the 22th of March
- 2010 have been given this permission through the
+ Source packages that shipped gcj-packages as of March 22nd,
+ 2010, have been given this permission through the
ratification of this policy.
</para>
 
Old 03-23-2010, 08:43 AM
Matthew Johnson
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

On Tue Mar 23 10:26, Niels Thykier wrote:
> I have compiled two patches against the current policy that I intend to
> apply Friday assuming there are no objections.

FYI I have already approved these two patches on IRC

Matt
--
Matthew Johnson
 
Old 03-23-2010, 08:58 AM
Sylvestre Ledru
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Le mardi 23 mars 2010 à 10:26 +0100, Niels Thykier a écrit :
> Hi
>
> I have compiled two patches against the current policy that I intend to
> apply Friday assuming there are no objections.
Nice work. Glad to see that finally evolving.

Could you just add a few bit on the gcj part ?
* What it is/was ?
* Why it is no longer allowed ?
* What kind of information are expected to grant a packager the
permission to ship gcj-code

Thanks
Sylvestre


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1269338328.12129.4775.camel@korcula.inria.fr">http ://lists.debian.org/1269338328.12129.4775.camel@korcula.inria.fr
 
Old 03-23-2010, 09:54 AM
Niels Thykier
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Sylvestre Ledru wrote:
> Le mardi 23 mars 2010 à 10:26 +0100, Niels Thykier a écrit :
>> Hi
>>
>> I have compiled two patches against the current policy that I intend to
>> apply Friday assuming there are no objections.
> Nice work. Glad to see that finally evolving.
>
> Could you just add a few bit on the gcj part ?
> * What it is/was ?

Personally I felt the first paragraph of the gcj part was enough. To the
best of my knowledge this is why the gcj stuff is. If you feel it is not
enough (and the addition draft below does not help), then I will need
some pointers to what you would like to see.

That being said I think it would be easier to understand if I replaced
"native code" with "machine code" and I intend to implement this with
the next diff.

> * Why it is no longer allowed ?
> * What kind of information are expected to grant a packager the
> permission to ship gcj-code
>

Sure, what do you think of this:

In the past gcj packages were added in order to improve
performance of Java libraries and programs. However, this
performance comes at the cost of size, extra compilation
time and creates architecture dependent packages.

A request for permission to add gcj should packages should
convince the Java Team that the performance boost of adding
the gcj package or packages out-weights the disadvantages.

The request and the permission may be limited to certain
architectures.

> Thanks
> Sylvestre
>
>

I will generate a new patch if you approve of the above.

~Niels
 
Old 03-23-2010, 12:14 PM
Sylvestre Ledru
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Le mardi 23 mars 2010 à 11:54 +0100, Niels Thykier a écrit :
> Sylvestre Ledru wrote:
> > Le mardi 23 mars 2010 à 10:26 +0100, Niels Thykier a écrit :
> >> Hi
> >>
> >> I have compiled two patches against the current policy that I intend to
> >> apply Friday assuming there are no objections.
> > Nice work. Glad to see that finally evolving.
> >
> Sure, what do you think of this:
>
> In the past gcj packages were added in order to improve
> performance of Java libraries and programs. However, this
> performance comes at the cost of size, extra compilation
> time and creates architecture dependent packages.
>
> A request for permission to add gcj should packages should
> convince the Java Team that the performance boost of adding
> the gcj package or packages out-weights the disadvantages.
>
> The request and the permission may be limited to certain
> architectures.
It is perfect and it also explains why we used gcj in the past.

Thanks
Sylvestre



--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1269350085.12129.5923.camel@korcula.inria.fr">http ://lists.debian.org/1269350085.12129.5923.camel@korcula.inria.fr
 
Old 03-23-2010, 12:33 PM
Matthias Klose
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

On 23.03.2010 11:54, Niels Thykier wrote:

Sylvestre Ledru wrote:

Le mardi 23 mars 2010 à 10:26 +0100, Niels Thykier a écrit :

Hi

I have compiled two patches against the current policy that I intend to
apply Friday assuming there are no objections.

Nice work. Glad to see that finally evolving.

Could you just add a few bit on the gcj part ?
* What it is/was ?


Personally I felt the first paragraph of the gcj part was enough. To the
best of my knowledge this is why the gcj stuff is. If you feel it is not
enough (and the addition draft below does not help), then I will need
some pointers to what you would like to see.

That being said I think it would be easier to understand if I replaced
"native code" with "machine code" and I intend to implement this with
the next diff.


* Why it is no longer allowed ?
* What kind of information are expected to grant a packager the
permission to ship gcj-code



Sure, what do you think of this:

In the past gcj packages were added in order to improve
performance of Java libraries and programs. However, this
performance comes at the cost of size, extra compilation
time and creates architecture dependent packages.


not only in the past.


A request for permission to add gcj should packages should
convince the Java Team that the performance boost of adding
the gcj package or packages out-weights the disadvantages.


this is always true for archs not having vm with a JIT.


The request and the permission may be limited to certain
architectures.


that should be removed. there is a list of these archs in
/usr/share/gcj/debian_defaults which should be sourced in debian/rules.
it's fine to build these packages on every arch. the empty package doesn't hurt,
and you won't have to make changes to the packaging if a new architecture is added.


the packages do make sense for architectures which only come with the ZeroVM in
OpenJDK, and no JIT.


Matthias


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BA8C33C.8070409@debian.org">http://lists.debian.org/4BA8C33C.8070409@debian.org
 
Old 03-23-2010, 12:35 PM
Matthias Klose
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

On 23.03.2010 10:26, Niels Thykier wrote:

Hi

I have compiled two patches against the current policy that I intend to
apply Friday assuming there are no objections.


mentioning default-jdk-doc would be useful.


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BA8C38B.5060601@debian.org">http://lists.debian.org/4BA8C38B.5060601@debian.org
 
Old 03-24-2010, 07:45 AM
Niels Thykier
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

I have decided to extract the GCJ part into its own patch. I have
created an interdiff between the last and the current version of the
fosdem06 patch. I would have made an interdiff for the GCJ part as well,
but it failed.

Matthias Klose wrote:
> On 23.03.2010 11:54, Niels Thykier wrote:
>> Sylvestre Ledru wrote:
>>> Le mardi 23 mars 2010 =C3=A0 10:26 +0100, Niels Thykier a =C3=A9crit =
:
>>>>[...]
>>
>> Sure, what do you think of this:
>>
>> In the past gcj packages were added in order to improve
>> performance of Java libraries and programs. However, this
>> performance comes at the cost of size, extra compilation
>> time and creates architecture dependent packages.
>=20
> not only in the past.
>=20

Added with the change above and the mention of its usefulness in the
absence of a JVM with a JIT compiler.

>> A request for permission to add gcj should packages should
>> convince the Java Team that the performance boost of adding
>> the gcj package or packages out-weights the disadvantages.

Clause added without change.

>=20
> this is always true for archs not having vm with a JIT.
>=20

If that is the case, why are we not doing more than a handful of
gcj-packages? Surely if the performance boost always out-weights the
extra costs, then the policy ought to have a "should" or "must" on
building these instead of a "only with permission".

>> The request and the permission may be limited to certain
>> architectures.

Clause excluded.

>=20
> that should be removed. there is a list of these archs in
> /usr/share/gcj/debian_defaults which should be sourced in debian/rules.=

> it's fine to build these packages on every arch. the empty package
> doesn't hurt, and you won't have to make changes to the packaging if a
> new architecture is added.
>=20

I have not mentioned this in the policy yet. What do the team feel about
this? Building empty gcj packages on architectures with a JIT compiler?

> the packages do make sense for architectures which only come with the
> ZeroVM in OpenJDK, and no JIT.
>=20

Thanks, did not know that. Which architectures are we talking about
here? All, all but i386 and amd64, or ...?

I had a look in "/usr/share/gcj/debian_defaults" and it contains all
architectures in "gcj_native_archs" (except m68k), but I was not sure if
it reflected the architectures without a JIT compiler.

> Matthias
>=20
>=20

~Niels

--------------000204050406030207090607
Content-Type: text/plain;
name="p2_fosdem_r2-r3.interdiff"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="p2_fosdem_r2-r3.interdiff"

ZGlmZiAtdSBwb2xpY3kueG1sIHBvbGljeS54bWwKLS0tIHBvbG ljeS54bWwJMjAxMC0wMy0y
MyAwMDozMDowMS43NzU0OTcwMjIgKzAxMDAKKysrIHBvbGljeS 54bWwJMjAxMC0wMy0yNCAw
ODo0NDo0Mi42OTU1MTMxMTkgKzAxMDAKQEAgLTEyOCwxMSArMT I4LDYgQEAKICAgICA8L3Bh
cmE+CiAKICAgICA8cGFyYT4KLSAgICAgIFRoZSBKYXZhIGJ5dG Vjb2RlICZtYXk7IGFkZGl0
aW9uYWxseSBiZSBzaGlwcGVkIGFzIG1hY2hpbmUgY29kZSwgYX MgcHJvZHVjZWQgZm9yIGV4
YW1wbGUKLSAgICAgIGJ5IHRoZSBHTlUgQ29tcGlsZXIgZm9yIE phdmEsIGluIGEgc2VwYXJh
dGUgYXJjaGl0ZWN0dXJlLXNwZWNpZmljIHBhY2thZ2UuCi0gIC AgPC9wYXJhPgotCi0gICAg
PHBhcmE+CiAgICAgICBQcm9ncmFtcyBhbmQgbGlicmFyaWVzIC ZzaG91bGQ7IGVuYWJsZSBK
VW5pdCB0ZXN0cywgaWYgdGhlc2UgYXJlIHByZXNlbnQuCiAgIC AgICBIb3dldmVyLCB0aGVz
ZSB0ZXN0cyAmbXVzdG5vdDsgbGVhZCB0byBidWlsZCBmYWlsdX Jlcy4KICAgICA8L3BhcmE+
CkBAIC0zMTYsNTAgKzMxMSw2IEBACiAgICAgICA8L3BhcmE+Ci AgICAgPC9zZWN0MT4KIAot
ICAgIDxzZWN0MSBpZD0icG9saWN5LWdjai1uYXRpdmUiPgotIC AgICAgPHRpdGxlPk5hdGl2
ZSBKYXZhIEJ5dGVjb2RlIChnY2ogcGFja2FnZXMpPC90aXRsZT 4KLQotICAgICAgPHBhcmE+
Ci0JSmF2YSBieXRlY29kZSBjb21waWxlZCBpbnRvIG5hdGl2ZS Bjb2RlIGlzIHJlZmVycmVk
IHRvIGFzCi0JZ2NqLWNvZGUgYW5kIHBhY2thZ2VzIGNvbnRhaW 5pbmcgZ2NqLWNvZGUgYXMg
Z2NqLXBhY2thZ2VzLgotICAgICA8L3BhcmE+Ci0KLSAgICAgID xwYXJhPgotIAlQYWNrYWdl
cyAmbXVzdG5vdDsgc2hpcCBnY2otY29kZSB3aXRob3V0IHRoZS BwZXJtaXNzaW9uIG9mCi0g
CXRoZSBKYXZhIHRlYW0gKDxlbWFpbD5kZWJpYW4tamF2YUBsaX N0cy5kZWJpYW4ub3JnPC9l
bWFpbD4pLgotCVNvdXJjZSBwYWNrYWdlcyB0aGF0IHNoaXBwZW QgZ2NqLXBhY2thZ2VzIGFz
IG9mIE1hcmNoIDIybmQsCi0JMjAxMCwgaGF2ZSBiZWVuIGdpdm VuIHRoaXMgcGVybWlzc2lv
biB0aHJvdWdoIHRoZQotCXJhdGlmaWNhdGlvbiBvZiB0aGlzIH BvbGljeS4KLSAgICAgIDwv
cGFyYT4KLQotICAgICAgPHBhcmE+Ci0gCVNvdXJjZSBwYWNrYW dlcyBjb21waWxpbmcgZ2Nq
LXBhY2thZ2VzICZtdXN0OyBCdWlsZC1EZXBlbmQgb24KLQkmZC 1qYmRlcDsuICBUaGUgZ2Nq
LXBhY2thZ2VzICZzaG91bGQ7IG9ubHkgYmUgc2hpcHBlZCBmb3 IgYSBzZWxlY3RlZAotIAlz
ZXQgb2YgYXJjaGl0ZWN0dXJlcy4KLSAgICAgIDwvcGFyYT4KLQ otICAgICAgPHBhcmE+Ci0g
CVRoZSBnY2otY29kZSAmbXVzdDsgYmUgaW5zdGFsbGVkIGluID xmaWxlbmFtZT4vdXNyL2xp
Yi9nY2ovPC9maWxlbmFtZT4KLQlhbmQgc2hpcHBlZCBpbiBhIH NlcGFyYXRlbHkgZnJvbSB0
aGUgb3JpZ2luYWwgamFyIGZpbGUuIFRoZSBnY2otcGFja2FnZQ otCSZtdXN0OyBhbHNvIGlu
c3RhbGwgdGhlIGNsYXNzbWFwIGZpbGUgZ2VuZXJhdGVkIGJ5IG FvdC1jb21waWxlIGluCi0J
PGZpbGVuYW1lPi91c3Ivc2hhcmUvZ2NqL2NsYXNzbWFwLmQvPC 9maWxlbmFtZT4uCi0gICAg
ICA8L3BhcmE+Ci0KLSAgICAgIDxwYXJhPgotCVRoZSBnY2otcG Fja2FnZSAmbXVzdDsgY2Fs
bCByZWJ1aWxkLWdjai1kYiBpbiB0aGUgcG9zdGluc3QgYW5kCi 0JcG9zdHJtIHNjcmlwdCwg
aWYgcmVidWlsZC1nY2otZGIgaXMgcHJlc2VudC4KLSAgICAgID wvcGFyYT4KLQotICAgICAg
PHBhcmE+Ci0JVGhlIGdjai1wYWNrYWdlICZtdXN0OyBkZXBlbm Qgb24gdGhlIHBhY2thZ2Ug
cHJvdmlkaW5nIHRoZSBqYXIKLQlmaWxlLCBpdCBpcyBhIG5hdG l2ZSBjb21waWxhdGlvbi4K
LSAJVGhlIHBhY2thZ2UgY29udGFpbmluZyB0aGUgamFyIGZpbG UgJm11c3Q7IGRlY2xhcmUg
ZWl0aGVyIGEKLQlTdWdnZXN0cyBvciBhIFJlY29tbWVuZHMgcm VsYXRpb25zaGlwIG9uIHRo
ZSBnY2otcGFja2FnZS4KLQlUaGlzIHJlbGF0aW9uc2hpcCAmbW F5OyBiZSBkaWZmZXJlbnQg
YmV0d2VlbiBhcmNoaXRlY3R1cmVzLgotICAgICA8L3BhcmE+Ci 0KLSAgIDwvc2VjdDE+Ci0K
ICAgICA8c2VjdDEgaWQ9InBvbGljeS1wb2xpdGljcyI+CiAgIC AgICA8dGl0bGU+TWFpbiwg
Y29udHJpYiBvciBub24tZnJlZTwvdGl0bGU+CiAgICAgICA8cG FyYT4K
--------------000204050406030207090607
Content-Type: text/x-diff;
name="p3_fosdem06-gcj.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="p3_fosdem06-gcj.patch"

Description: Applies the GCJ part of the FOSDOM 2006 draft. The original
proposals have been adapted to better fit the current time.
.
URL: http://wiki.debian.org/Java/Draft

--- policy.xml.orig 2010-03-24 08:49:38.103512020 +0100
+++ policy.xml 2010-03-24 09:15:47.944514335 +0100
@@ -14,6 +14,8 @@
<!ENTITY d-jdk "<emphasis>default-jdk</emphasis>">
<!ENTITY d-jbdep "<emphasis>default-jdk-builddep</emphasis>">
<!ENTITY d-jdoc "<emphasis>default-jdk-doc</emphasis>">
+<!ENTITY JVM "<acronym>JVM</acronym>">
+<!ENTITY JIT "<acronym>JIT</acronym>">
]>
=20
<book>
@@ -128,6 +130,11 @@
</para>
=20
<para>
+ The Java bytecode &may; additionally be shipped as machine code, a=
s produced for example
+ by the GNU Compiler for Java, in a separate architecture-specific =
package.
+ </para>
+
+ <para>
Programs and libraries &should; enable JUnit tests, if these are p=
resent.
However, these tests &mustnot; lead to build failures.
</para>
@@ -311,6 +318,64 @@
</para>
</sect1>
=20
+ <sect1 id=3D"policy-gcj-native">
+ <title>Native Java Bytecode (gcj packages)</title>
+
+ <para>
+ Java bytecode compiled into native code is referred to as
+ gcj-code and packages containing gcj-code as gcj-packages.
+ </para>
+
+ <para>
+ gcj-packages has been added in order to improve
+ performance of Java libraries and programs. This is
+ particularly useful on architectures where the JVM
+ does not have a &JIT;. However, this performance comes=20
+ at the cost of size, extra compilation time and
+ creates architecture dependent packages.
+ </para>
+
+ <para>
+ Packages &mustnot; ship gcj-code without the permission of
+ the Java team (<email>debian-java@lists.debian.org</email>).
+ Source packages that shipped gcj-packages as of March 22nd,
+ 2010, have been given this permission through the
+ ratification of this policy.
+ </para>
+
+ <para>
+ A request for permission to add gcj should packages should
+ convince the Java Team that the performance boost of adding
+ the gcj-packages out-weights the disadvantages.
+ </para>
+
+ <para>
+ Source packages compiling gcj-packages &must; Build-Depend on
+ &d-jbdep;. The gcj-code &should; only be shipped for a selected
+ set of architectures.
+ </para>
+
+ <para>
+ The gcj-code &must; be installed in <filename>/usr/lib/gcj/</filename>=

+ and shipped in a separately from the original jar file. The gcj-package=

+ &must; also install the classmap file generated by aot-compile in
+ <filename>/usr/share/gcj/classmap.d/</filename>.
+ </para>
+
+ <para>
+ The gcj-package &must; call rebuild-gcj-db in the postinst and
+ postrm script, if rebuild-gcj-db is present.
+ </para>
+
+ <para>
+ The gcj-package &must; depend on the package providing the jar
+ file, it is a native compilation.
+ The package containing the jar file &must; declare either a
+ Suggests or a Recommends relationship on the gcj-package.
+ </para>
+
+ </sect1>
+
<sect1 id=3D"policy-politics">
<title>Main, contrib or non-free</title>
<para>

--------------000204050406030207090607
Content-Type: text/x-diff;
name="p2_fosdem06_r3.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="p2_fosdem06_r3.patch"

Description: Applies the FOSDOM 2006 draft. The original proposals have b=
een
adapted to better fit the current time. The GCJ changes have been moved =
to
a separate patch.
.
This excludes the "Java virtual machines" part based on feedback on #365=
408
URL: http://wiki.debian.org/Java/Draft
Closes: #227587
--- policy.xml.orig 2010-03-22 20:04:35.248312944 +0100
+++ policy.xml 2010-03-24 08:44:42.695513119 +0100
@@ -11,6 +11,9 @@
<!ENTITY j2r "<emphasis>java2-runtime</emphasis>">
<!ENTITY jc "<emphasis>java-compiler</emphasis>">
<!ENTITY j2c "<emphasis>java2-compiler</emphasis>">
+<!ENTITY d-jdk "<emphasis>default-jdk</emphasis>">
+<!ENTITY d-jbdep "<emphasis>default-jdk-builddep</emphasis>">
+<!ENTITY d-jdoc "<emphasis>default-jdk-doc</emphasis>">
]>
=20
<book>
@@ -119,15 +122,14 @@
<para>
Both &must; be shipped as Java bytecode (<filename>*.class</filena=
me>
files, packaged in a <filename>*.jar</filename> archive) and with
- an "Architecture: all".
- It &may; additionally be shipped as machine code, as produced for =
example
- by the GNU Compiler for Java, in a separate architecture-specific
- package.
+ an "Architecture: all". There are rare exceptions to this such as =
Eclipse
+ SWT. Exceptions to this rule can only be granted by the Java Team.=

+ Requests &must; be sent to <email>debian-java@lists.debian.org</em=
ail>.
</para>
=20
<para>
- This policy does not yet address the issue of documentation (for i=
nstance
- HTML pages made with javadoc).
+ Programs and libraries &should; enable JUnit tests, if these are p=
resent.
+ However, these tests &mustnot; lead to build failures.
</para>
=20
<sect1 id=3D"policy-vm">
@@ -257,9 +259,7 @@
</para>
=20
<para>
- Java libraries &must; depend on the needed runtime environment
- (&j1r; and/or &j2r but &should; not depend (only suggest)
- java-virtual-machine.
+ Class files in a java library &must; be built with debug symbols.
</para>
=20
<para>
@@ -295,6 +295,20 @@
architecture-specific and follow the usual libXXX[version]-java
naming convention.
</para>
+
+ <para>
+ Java library packages &should; compile the javadoc API of the
+ library. The API &must; link against the javadoc API of the
+ libraries it depends on. This includes the core java classes,
+ which are provided by &d-jdoc;. The API &must; be registered with
+ doc-base and &must; be installed in
+ <filename>/usr/share/doc/&lt;package&gt;/api/</filename> or
+ <filename>/usr/share/doc/&lt;package&gt;/api-&lt;component&gt;/</filena=
me>.
+ </para>
+ <para>
+ The API &must; be place in a separate doc package. This package
+ &must; depend on the doc packages it was linked against.
+ </para>
</sect1>
=20
<sect1 id=3D"policy-politics">
@@ -322,6 +336,8 @@
url=3D"http://www.gnu.org/software/classpath">GNU-Classpath</ulink>=
has
a list of free versions), it cannot go to main. If
your package itself is free, it &must; go to contrib.
+ Since java libraries do not have a runtime dependency,
+ this rule does not apply to them.
</para>
</listitem>
=20
@@ -444,6 +460,11 @@
will be integrated in the policy, one day).
</para>
</listitem>
+ <listitem>
+ <para>
+ Java packages &should; be built with &d-jdk; if possible.
+ </para>
+ </listitem>
</itemizedlist>
=20
</chapter>

--------------000204050406030207090607--
 
Old 03-24-2010, 07:49 AM
Niels Thykier
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Matthias Klose wrote:
> On 23.03.2010 10:26, Niels Thykier wrote:
>> Hi
>>
>> I have compiled two patches against the current policy that I intend to
>> apply Friday assuming there are no objections.
>
> mentioning default-jdk-doc would be useful.
>
>

It is mentioned once:

Java library packages &should; compile the javadoc API of the
library. The API &must; link against the javadoc API of the
libraries it depends on. This includes the core java classes,
which are provided by &d-jdoc;. The API &must; be registered with
doc-base and &must; be installed in
<filename>/usr/share/doc/&lt;package&gt;/api/</filename> or
<filename>/usr/share/doc/&lt;package&gt;/api-&lt;component&gt;/</filename>.

&d-jdoc; is expanded to <emphasis>default-jdk-doc</emphasis>.

But yes, I feel that the default-* packages should definitely be listed
in the policy as "interesting packages", but I intend to save that for a
later patch.

~Niels
 

Thread Tools




All times are GMT. The time now is 04:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org