Hello,

Java policy on Java libraries (Ch. 2.4.) reads [1]:

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 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.

Some package must also provide a symbolic link from
packagename-extraname.jar to the most compatible version of the
available packagename-extraname-version.jar files.

However, it seems that packages built with maven-{debian,repo}-helper
default settings contain the opposite: JAR archives are named packagename-extraname.jar, and packagename-extraname-version.jar are
symbolic links to packagename-extraname.jar. For example see libcommons-lang3-java.

This looks like a contradiction to me. Or am I just misreading the policy?

[1] /usr/share/doc/java-policy/debian-java-policy.txt.gz, java-policy 0.57

Best,
Andrius

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Am Freitag, dem 15.10.2021 um 12:41 +0300 schrieb Andrius Merkys:

Hello,

Java policy on Java libraries (Ch. 2.4.) reads [1]:

    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 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.

    Some package must also provide a symbolic link from
    packagename-extraname.jar to the most compatible version of the
    available packagename-extraname-version.jar files.

However, it seems that packages built with maven-{debian,repo}-helper
default settings contain the opposite: JAR archives are named packagename-extraname.jar, and packagename-extraname-version.jar are
symbolic links to packagename-extraname.jar. For example see libcommons-lang3-java.

This looks like a contradiction to me. Or am I just misreading the policy?

[1] /usr/share/doc/java-policy/debian-java-policy.txt.gz, java-policy 0.57

Indeed, that looks like a bug in libcommons-lang3-java or rather maven-debian- helper to me. I have just checked some other Maven packages and there the policy is implemented correctly. The bug in libcommons-lang3-java could be related to the relocation feature in the poms file but I haven't looked closer yet.

Regards,

Markus

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmFpZ1NfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7 UeSYqw/+LM1ynvzi7yKky26ZJHdJcEZzXVu23r4vJGw+ROw28VXfyFBOEYHVFLFj +FWeeojdXYZemfEV2OKol35yCkbGsQHf2JrfRMnVaSCEnDLR7RNTsFic96+rPUVm VM0ixtMtBbhSLYkv98yf2ByjKKWRcQz0/aqUX+WKsAEyVQwxjfexurxNt4Ydsx9N S6L2m92oGSfjjOPsgK6CWbSyz7DP5M+ZP2D4OHhj5J3WDqeyJcBwvLw6/MzwR7FM c+AebDqZ5RsfrcXYKpfmy80GYUQYmacKfUIVH0FyLVz0B37OXCBW8eZX6bfs9v/0 3f69au51++/Hssy+qUc+pGh5B1V729e5OssAPILRIzGpJ4Ql2HEpZMOUY0/4Vl72 H9u8UxfdPvKN0dKmXq9VWQQlOz5jiDlKbIzxp89dGROaYGdr9BcXhG/DdoIEwfQI AyNz/MDS6Wx9TjjtTVacZpU6tOhq/SktOXhcz/7UrGouGIUl1jvx6mThd1fp4+U+ RhFZSliAGDkprWgBOvQPzoNuCumx/FvA1WPvgpWH6AIa8qhKT5DY9W+uYAMtmXl9 rncBRahCJxbJDwXU9MtHDTYzXafFZJ6KfaTJUD00+ge5xmmqM+Tcwmz1CSa8s599 nOtf7jvpEMuDiy8ZJU+S8t12f/QnUrj92+G4NnhQiPyKBrepXkU=
=AY9Y
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Markus,

On 2021-10-15 14:34, Markus Koschany wrote:

Indeed, that looks like a bug in libcommons-lang3-java or rather maven-debian-
helper to me. I have just checked some other Maven packages and there the policy is implemented correctly. The bug in libcommons-lang3-java could be related to the relocation feature in the poms file but I haven't looked closer
yet.

Thanks for giving it a look. However, it think that maven-debian-helper
should not be placing files against the policy by default. I usually use mh_make for initial packaging, and now I see that most of my packages
are violating MUST of a policy because of that.

I took a quick look at my /usr/share/java, and these seems to be quite
some packages with versionless JARs and versioned symbolic links [1],
just to name a few (out of 125):

libantlr3-runtime-java
libcompress-lzf-java
libhttpclient-java
libmorfologik-stemming-java
libsurefire-java

Not sure though what is the impact of this policy inversion. Most of Java-related software seems to read both regular files and symbolic
links transparently.

[1] $ comm -1 -2 <(find /usr/share/java/ -type l | grep -P
'[-][\.0-9]+\.jar$' | xargs -n1 dpkg -S | cut -d : -f 1 | sort) <(find /usr/share/java/ -type f | grep -P '[-][^\.0-9]+\.jar$' | xargs -n1 dpkg
-S | cut -d : -f 1 | sort) | uniq

Best,
Andrius

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 15/10/2021 à 15:17, Andrius Merkys a écrit :

Not sure though what is the impact of this policy inversion. Most of Java-related software seems to read both regular files and symbolic
links transparently.

There isn't much impact, both styles are fine in my opinion.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 2021-10-18 10:31, Alexandre Rossi wrote:

Not sure though what is the impact of this policy inversion. Most of
Java-related software seems to read both regular files and symbolic
links transparently.

There isn't much impact, both styles are fine in my opinion.

This seems to trigger https://lintian.debian.org/tags/bad-jar-name

Exactly. Thus lintian seems to follow the current Java policy and
correctly emit warnings.

I am trying to understand if this is a bug in maven-*-helper, or a
result of overly strict policy. One of these should be changed.

Best,
Andrius

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Not sure though what is the impact of this policy inversion. Most of Java-related software seems to read both regular files and symbolic
links transparently.

There isn't much impact, both styles are fine in my opinion.

This seems to trigger https://lintian.debian.org/tags/bad-jar-name

Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Not sure though what is the impact of this policy inversion. Most of
Java-related software seems to read both regular files and symbolic
links transparently.

There isn't much impact, both styles are fine in my opinion.

This seems to trigger https://lintian.debian.org/tags/bad-jar-name

Exactly. Thus lintian seems to follow the current Java policy and
correctly emit warnings.

I am trying to understand if this is a bug in maven-*-helper, or a
result of overly strict policy. One of these should be changed.

I finally found some time to look into this and came up with a patch.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007923

Thanks,

Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)