Hi! On Fri, 2013-08-16 at 08:58:02 +0200, Guillem Jover wrote: > On Thu, 2013-08-15 at 19:42:17 -0400, Asheesh Laroia wrote: > > Package: dpkg > > Version: 1.16.10 > > Severity: normal > > > Summary: In lib/dpkg/compress.c, I would like it if dpkg did not > > store timestamps in the gzip files. That way, the creation of the > > data.tar.gz would be deterministic.
> > In particular, when I build a binary package with the very same > > contents twice, I see that data.tar.xz and control.tar.gz are both > > different although they have the same contents (even timestamps). > > Binary files one/control.tar.gz and two/control.tar.gz differ > > Binary files one/data.tar.xz and two/data.tar.xz differ > > > > In 1.16.10 I would add '-n' to the call to 'gzip' in a pipe. In > > curent dpkg git, I believe this may be fixed, but I am not sure. I > > am filing this bug so there is a clear statement of the general > > problem in the BTS, at least! dpkg has not used the gzip command for a very long long time (prior to dpkg 1.9.x), and zlib does not initialize the gzip header, so the timestamp should be 0. If there are differences these should come from something else, like different tar files fo example. I can of course add the option to the fallback command code, just out of correctness, but that will not fix any difference you are currently seeing. > The same will apply when building that deb package multiple times, the > timestamps will change for the ar headers. And I don't really want to > lose that data, because currently is the only place were the build > time information is recorded. Do you only care that the members > themselves are deterministic or the whole deb package? > > I think I'd be fine with not storing the timestamps in the compressed > members themselves, but not about the ar container. This still applies, though. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
