Marcus Better wrote: > Arnaud Vandyck wrote: >> It's a good idea to remove generated javadoc and jar files and classes. > > Well, let's agree to disagree. :) > >> They can be removed to use less space and be sure not to include code >> that has been build with non free dependencies. > > The space argument is rather weak IMHO, and certainly shouldn't warrant > rebuilding a source tarball only for that purpose. (Or do you have a source > for this advice?) And avoiding to install pre-built binaries is easy. > > (It's slightly more difficult to ensure that pre-built third-party jars are > not used during the build, but here we agree that those should be removed > from the source archive.)
This is the ideal solution - to have pre-built third-party jars removed by upstream - but this can be difficult in practice. Many upstreams have no intention or interest in building their software and all third-party libraries from scratch every time, nor do they always work on systems where third-party libraries are installed system-wide (meaning that the third-party jars often end up in the source tree). So I think it's pretty common to find third-party jars inside sources for much of the Java software out there. (After all, third-party jars are kind of the beauty of Java - shared libraries without the fuss of working about the originating operating system, or architecture, or gcc version...) I'd like to see us establish a best practice with respect to generated jar files, classes, javadoc, and third-party jars and add it to the java policy. Personally, I think the presence of build artifacts warrants repacking the upstream source, and any third-party jars requires it. This ensures that the resulting binary deb is built from the packages sources + dependencies, and nothing else. However, I'm open to other opinions on the matter. 0.02, tony
signature.asc
Description: OpenPGP digital signature
