Re: Repackaging question
Marcus Better marcus at better.se writes: Andrew Haley wrote: 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. That may be a valid argument, but there are more troubling cases. For instance we ship a lot of packages that build with Maven, but since we don't have Maven in Debian, we use the included, pre-generated, Ant build file instead. What should we do about those? I'd suggest looking at whatever solution JPackage came up with, as well. I believe they (i.e. Ralph Apel) figured out how to package it in a way that it uses the jars in the packaging system rather than whatever the default is (network from ibiblio, I think), but I'm not sure. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
On Wed, 13 Dec 2006, Marcus Better wrote: Andrew Haley wrote: 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. That may be a valid argument, but there are more troubling cases. For instance we ship a lot of packages that build with Maven, but since we don't have Maven in Debian, we use the included, pre-generated, Ant build file instead. What should we do about those? We also ship the auto-tools generated configure file, although that's somewhat different since we also ship auto-tools if you do want to rebuild this. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Marcus Better writes: Andrew Haley wrote: 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. That may be a valid argument, but there are more troubling cases. For instance we ship a lot of packages that build with Maven, but since we don't have Maven in Debian, we use the included, pre-generated, Ant build file instead. What should we do about those? if these packages are in main, file a RC report and remove them, at least from testing. I don't care that much about contrib. Such packages may exist in non-free. Then package maven and maven2. which packages are these? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Matthias Klose wrote: Marcus Better writes: instance we ship a lot of packages that build with Maven, but since we don't have Maven in Debian, we use the included, pre-generated, Ant build file instead. What should we do about those? if these packages are in main, file a RC report and remove them, at least from testing. That's a bit drastic, no? Those packages are no different from packages with pre-generated configure scripts and the like, and those are accepted in main, IIRC. Then package maven and maven2. Good idea, why don't you try it?, to quote someone on -project recently. :-) Actually I'm planning to have a go at those, but they are rather complicated. which packages are these? AFAICT, all of Jakarta Commons, dom4j, jaxen, and probably a lot more. Plus upcoming Tomcat 6. Remove those (especially Commons) and we might as well forget the Java support in Debian. A mass bug filing of wishlist bugs, with an appropriate usertag, would be a good first step though. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Marcus Better writes: Matthias Klose wrote: Marcus Better writes: instance we ship a lot of packages that build with Maven, but since we don't have Maven in Debian, we use the included, pre-generated, Ant build file instead. What should we do about those? if these packages are in main, file a RC report and remove them, at least from testing. That's a bit drastic, no? Those packages are no different from packages with pre-generated configure scripts and the like, and those are accepted in main, IIRC. you can recreate them using packages in main. you can't do this with the maven jars. Then package maven and maven2. Good idea, why don't you try it?, to quote someone on -project recently. :-) Actually I'm planning to have a go at those, but they are rather complicated. which packages are these? AFAICT, all of Jakarta Commons, dom4j, jaxen, and probably a lot more. Plus looked at libcommons-logging-java, jaxen, dom4j, which do not use maven for the build. so which sources are actually including maven jars? upcoming Tomcat 6. that's easy. package it for non-free or don't package it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
Matthias Klose wrote: looked at libcommons-logging-java, jaxen, dom4j, which do not use maven for the build. so which sources are actually including maven jars? I think we are talking about two different things here. No packages include maven jars. Some packages use maven upstream, but in all cases we build them with Ant. The Ant build.xml file was generated upstream by maven. (And most build files are quite easy to recreate by hand if we were forced to do it.) Marcus -- 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
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 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
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
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
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
It's preferable to leave the package contents exactly as upstream, and just repackage into a tarball. In that case you don't need to tag the orig filename. See http://people.debian.org/~daniel/documents/packaging.html for some recommendations. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repackaging question
[Please CC I am not subscribed] Hello, It's preferable to leave the package contents exactly as upstream, and just repackage into a tarball. In that case you don't need to tag the orig filename. Generally speaking yes, but the Debian Java Policy suggests, that class files should be removed from upstream release [1]. Since for UMLet I have a zip which contains a jar which contains class files and sources I am not sure how to handle that case. Regards Ben [1] http://www.debian.org/doc/packaging-manuals/java-policy/c173.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Repackaging question
[Please CC, I am not subscribed] Hello, I have an upstream release umlet.zip with the given content: umlet.zip +- com.umlet.plugin +- someStuff +- umlet.jar + .class file hierarchy + src + .java file hierarchy (i.e. umlet.zip contains a directory com.umlet.plugin which contains a umlet.jar file which in turn contains the java source and binary class files) My intention is, to repackage it to: umlet_version.orig.tar.gz +- umlet +- someStuff +- src + .java file hierarchy Does this sound OK? Should I refrain from renaming the toplevel directory from com.umlet.plugin to umlet? Does the package need an additional name tag to the orig filename? Thanks Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
