tarball in tarball: opinions
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
* 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
* 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
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
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
Jay Berkenbilt <email@example.com>