In light of the upcoming change to 3.0 (quilt) source package format and Raphael Hertzog's guidelines suggesting that we not use tarball in tarball packages, I'm re-evaluating my habit of using this pattern.
There are many reasons that I prefer to use tarball in tarball, but there are two that I can't find a straightforward way around with the new format: * I like to have an exact copy of the downloaded source tarball with the same md5 checksum, gpg detached signature, etc. Using the rules/tarball.mk from cdbs provides a very convenient way of handling this. * I manage my debian directories in subversion, and I use svn-buildpackage to build. I always use "mergeWithUpstream". Sometimes I want to do something more involved, so I just manually extract my .orig.tar.gz files. I can't do this without tarball in tarball if my packages either contain their own debian directories that I don't use or if they extract to a directory other than pkg-version. So, is using tarball in tarball considered "bad" these days? Is it viewed as an approach that once had its time but is now discouraged, or is it just a matter of personal preference and creating a README.source that tells the user what to do file makes it all okay? I want my packages to be in the best possible shape, so I'm trying to decide whether I should go to the trouble of changing my personal packaging habits to work around the two issues above. Some of these will be easier to handle after we can switch to 3.0 (quilt), but as far as I know, there is no way to replace your .orig.tar.gz without changing the package version, and I don't want to introduce epochs for this. Advice welcome. In the absence of any specific suggestions, I'll just continue to use tarball in tarball and will wait to restructure my packages until after we can switch to 3.0 (quilt). I'm going to try to make a decision soon since I have a new upstream version of ICU ready to upload to experimental as soon as I resolve this. Thanks. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
