Re: Repackaging question
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
Re: Repackaging question
On 12/12/06, Marcus Better <[EMAIL PROTECTED]> 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. In some cases, the size does matter :-D But it's not a reason to be rejected, but see http://ftp-master.debian.org/REJECT-FAQ.html +-- ! Contents of orig.tar.gz: ! ! If you rebuild the orig.tar.gz (in the few cases this is needed, ! most of the times it is NOT) - be sure to not include .so/.a/other ! compiled files. You should also exclude cvs/ .svn/ ! .whatever_your_version_control_system_has directories ! you added. +-- Also, you don't know if the jar files contains parts that could be not dfsg compliant (like Andrew said) and we need to keep the repository legal. Cheers, -- Arnaud Vandyck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Hello, > > 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. I have another argument for repackaging in this particular case: The upstream zip contains a jar, which in turn contains the source code of the program. However, I need to patch the source contained in the jar. This is quite painful in terms of applying those patches. Regards Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Arnaud Vandyck writes: > On 12/6/06, Marcus Better <[EMAIL PROTECTED]> wrote: > > Benjamin Mesing wrote: > > > Generally speaking yes, but the Debian Java Policy suggests, that class > > > files should be removed from upstream release [1]. > > > > That advice is plain wrong. (And it's not part of the actual Java policy as > > the page says.) > > No, it's not. > > It's a good idea to remove generated javadoc and jar files and classes. Very much so. Unless you build from source, you have no way to know that the binaries correspond to that source code. You can't even guarantee that you're not violating the GPL, which requires you to provide source code on demand. > > Many Java packages come with jar files for dependencies, > > i.e. external code where the source is not included in the > > upstream tarball. Such binaries must be removed and the package > > should then get a +dfsg suffix. > > > > However a .jar or .class file built from included source code > > should not be removed (but obviously they must not be installed > > in Debian, but rather the sources must be rebuilt). > > They can be removed to use less space and be sure not to include code > that has been build with non free dependencies. That too. This is all to do with basic free software hygiene. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
On 12/6/06, Marcus Better <[EMAIL PROTECTED]> wrote: Benjamin Mesing wrote: > Generally speaking yes, but the Debian Java Policy suggests, that class > files should be removed from upstream release [1]. That advice is plain wrong. (And it's not part of the actual Java policy as the page says.) No, it's not. It's a good idea to remove generated javadoc and jar files and classes. Many Java packages come with jar files for dependencies, i.e. external code where the source is not included in the upstream tarball. Such binaries must be removed and the package should then get a +dfsg suffix. However a .jar or .class file built from included source code should not be removed (but obviously they must not be installed in Debian, but rather the sources must be rebuilt). They can be removed to use less space and be sure not to include code that has been build with non free dependencies. -- Arnaud Vandyck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
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.) Speaking of repacking, I just noticed that the tarball for libxala2-java has lots of jars in it. I'll try to fix it... pgpuyatrPQaBA.pgp Description: PGP signature
