Re: tarball in tarball: opinions
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@example.com>, 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 <firstname.lastname@example.org>