[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Correct way of providing uncompressed data.tar



On Thu, 2013-12-05 at 16:46 +0100, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2013-12-05 at 13:19:57 +0100, Roland Stigge wrote:
> > in linux-source-3.11, we have an issue due to unclear procedure how to
> > use uncompressed data.tar files:
> > 
> > http://bugs.debian.org/725492
> > 
> > While lintian rejects packages with data.tar (in contrast to the
> > compressed data.tar.{...} variants), an uncompressed data.tar.gz that
> > the kernel is currently using (dpkg-source -Xgzip -z0) triggers problems
> > in apt-ftparchive.
> 
> > To implement a correct fix, Ben asked for a decision by dpkg
> > maintainers, FTP team and policy. Basically, the question is if
> > uncompressed data.tar is the correct way (for me, this would be the
> > logical consequence), or rather uncompressed data.tar.gz as linux
> > currently does, but which isn't actually gzip formatted file, or sth. else.
> > 
> > See also http://bugs.debian.org/718330
> 
> 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?

> 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.

Ben.

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: