On Thu, Jun 12, 2008 at 11:03:58AM +0200, Raphael Hertzog wrote: > On Thu, 12 Jun 2008, Alexander Sack wrote: > > On Sun, Jun 08, 2008 at 06:11:57PM +0200, Raphael Hertzog wrote: > > > In several cases the usage of tarball(s) in tarball is justified by the > > > fact that several upstream tarballs have to be combined. The new format > > > does support unpacking of multiple upstream tarballs and as such, you > > > probably want to defer fixing this bug until the new format is accepted > > > and directly make usage of this new feature. > > > > > > If your package only contains a single tarball, you might want to > > > reconsider the choice of using a tarball inside a tarball and > > > handle the build like do most other Debian packages. > > > > Do i really need to eliminate my embedded tarball? I have no changes > > outside the debian/patches/. > > Well, if the source package is using the new format, during build > of a new source package it does want to apply patches on top of > the extracted .orig.tar.gz and obviously if the new orig.tar.gz doesn't > contain the required files to patch (because they are in the tarball), it will > fail: > > dpkg-source: info: building icedove using existing > ./icedove_2.0.0.14.orig.tar.gz > dpkg-source: failure: quilt --quiltrc /dev/null push main-fsh gave error exit > status 1 > > Using tarball inside tarball goes against the spirit of the format evolution > that adds the required features so that a package is ready for further > modifications directly after "dpkg-source -x". >
But isnt that the same for any patchsystem package? or will you apply some rule in future on dpkg-source -x to guarantee that its in "ready for modifications" state? - Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
