On Thu, Nov 08, 2007 at 08:22:06PM +0530, Kumar Appaiah wrote: > On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: > > I don't know much about java, but if those are just compilations of > > things for which the source is also in the tarball, there is no need to > > repackage. You can remove them in the clean target in debian/rules, for > > example, to make sure they are regenerated. But of course I may be > > completely missing the point. :-) > > The idea is that FTP master rejects abt binary content in your > orig.tar.gz for which you don't have source. So, if you package for > Java, remove all the jars, package them from their source, and > repackage your original program (Build-)?Depending on the others. Ah, yes. If the source is in a different package, then you need to remove them indeed. > > > 1) Should I convert eol markers (fromdos)? Or at least should I fix > > > the half a dozen files which have CRLF+CR as eol markers? > > > > I wouldn't do that. Repackaging is done to make the tarball complient > > with our standards, not to beautify it. If this conversion is a good > > idea (and I agree that it is), then that is an upstream issue, and it > > should be fixed there. Asking them about it is a good idea, changing it > > in the package is not IMO. > > I had to do this, because this caused some build failed for some > reason (I don't recall, but my mentor asked me to do it). Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged "because some files had to be removed", she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. > Also, my patches looked too ugly. And that's not an argument not to use it. :-) If you need to do ugly things, then it should look ugly. Putting those changes somewhere where they're hard to see may cause other problems which are hard to track down (not for you, but for other people who are expecting the have the original source). Especially if those changes are needed to make the build work, it is important that they are visible like other changes, and that's in the .diff.gz (directly or through a patch system, whatever you prefer). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature