On 25 August 2017 at 16:20, Chris Lamb <[email protected]> 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
