Bug#873211: lintian: does not warn about .class binaries
On 25 August 2017 at 16:20, Chris Lamb <lamby@debian.org> wrote:
> Hi Carnë,
>
>> While improving the packaging of a Debian package, I found that the
>> source release included .class files
>
> I guess we should be explicit about the problem we are trying to
> solve here; ie. which of:
>
> a) That upstream ships .class files to begin with (which I worry and
> suspect might be rather common in Java packages?)
>
> b) We ship binary packages with .class files. This is not only quite
> common from a quick grep, but it's not that much different from shipping
> a .jar, surely?
>
> c) We don't recompile whatever .class files end up in the binary,
> potentially meaning we are missing the source, etc.
>
> :)
>
Hi Chris
The problem I'm reporting is c), the files are not recompiled.
In the case where I found this issue (imagej package), the debian
binary release included the class files as compiled by upstream. The
supposed source is available but 1) their build system is configure to
skip those class files during compilation and simply and just copy
them for the jar file, and 2) they are dependent on MacOS java
extensions and so can't even be built in the first place.
This is not a bug report against the imagej package, I have already
fixed this issue there [1], which is why I didn't go into details. It
would just be nice if lintian could have caught this before since
apparently this has been an issue on this package for a very long
time.
Also, sicne you mention that b) is common, the java policy [2] states
that class files should be packaged inside a jar file so I guess it
shouldn't be common so maybe it should be checked for by lintian too?
Thank you
Carnë
[1] https://anonscm.debian.org/cgit/debian-med/imagej.git/tree/debian/patches/drop-mac-plugins.patch
[2] https://www.debian.org/doc/packaging-manuals/java-policy/c50.html
Reply to: