Thanks for all the input on tarball within tarball. I will stop using that format for all my packages with the possible exception of ICU which contains its own debian directory.
I was aware of the fact that dpkg-source handles the tarball nnot extracting to package-version and have, in fact, advised others that repackaging the orig.tar.gz to get around this is not necessary. One of my own packages (psutils) is this way. My point wasn't that dpkg-source doesn't handle it, but that it makes it somewhat less convenient to manually extract the source over top of my svn-controlled debian directories. I was not aware of svn-buildpackage --svn-export, pointed out by Magnus Holmgren <[EMAIL PROTECTED]>, and I think that will solve my problem quite nicely and prevent me from writing my own script that duplicates the logic in dpkg-source. With regard to the ICU packages, which include their own debian directory, I tried unsuccessfully two years ago to convince upstream to drop this. There has been a recent change of leadership in the project, and I have (prior to my sending out my message to debian-devel), post a bug to their bug tracking system requesting that they drop the debian directory. If they don't, I may regenerate the orig.tar.gz as I do not, but instead of using a tarball within a tarball, I'll just push everything down one level. Once the 3.0 (quilt) format becomes acceptable to use for regular packages in the archive, this becomes a non-issue, and I can use the upstream source download as the .orig.tar.gz file. Thanks for all the input and tips. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
