Hi! On Wed, 2013-12-18 at 04:46:47 +0000, Ben Hutchings wrote: > On Thu, 2013-12-05 at 16:46 +0100, Guillem Jover wrote: > > I've had a working fix for 718295 since end of July, but I've not > > applied it as it would remove a currently used misfeature with no > > substitute. As long as the data.tar support in general is so poor [0] > > and at least something like linux-source-3.11 uses the uncompressed > > tar.gz trick it would seems like a disservice to change it now. > > I'm not clear on what your fix is. Is it to treat -z0 as -z1?
Oh sorry, the fix is to correctly treat -Zgzip -z0 as -Znone, as documented, and generate a proper «data.tar» w/o the .gz extension. > > But I do think those .deb packages are bogus, and they break the > > assumption that .deb packages can be handled (w/o hacks) by standard > > Unix tools (in this case gzip needs a --force option to comply with > > the request). Sorry, should have updated my comment on the bug report > > clarifying that. > > > > The danger is that not fixing it, means tools might start supporting > > the bogusly created packages, but those have existed for a long time > > already, so they might need to anyway… Has someone tried recompressing > > linux-source-3.11 with something like -Zgzip -z1 as proposed in that > > bug report to see how it turns out (space and time-wise), if that > > happened to be acceptable, I'd happily push the fix for dpkg 1.17.4. > [...] > > Not so bad, after all: > > $ grep name /proc/cpuinfo | head -1 > model name : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz > $ time gzip -c1 data.tar > /tmp/data.tar.gz > real 0m2.557s > user 0m2.528s > sys 0m0.028s > $ ls -l data.tar /tmp/data.tar.gz > -rw-r--r-- 1 ben ben 77352960 Dec 18 04:10 data.tar > -rw-rw---- 1 ben ben 77310312 Dec 18 04:11 /tmp/data.tar.gz > > It seems there's enough zero-padding in the tar headers that gzip can > still save a little! So I'm going to change to -z1 for the next upload. Ah wonderful! Ben, thanks for testing. Then I'll queue the fix for dpkg targetted at whatever version happens after the next linux upload. I'm guessing this is the only affected package in the archive? Otherwise it would be nice to know before uploading such fixed dpkg. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218051432.ga26...@gaara.hadrons.org
