On Wed, Feb 08, 2012 at 03:06:46PM +0100, Adam Borowski wrote: > gzip's output is likely to change: > * on a new version > * after a bugfix (including security ones) > * on a different architecture > * with different optimizations > * with a different implementation (like those parallel ones) > * possibly with a different moon phase > Especially the first is pretty guaranteed to bite: whenever the upstream > does a small improvement, binaries in the archive get invalidated until > rebuilt with the new gzip.
Checking with a of 82613 files, compressing each file with gzip -n9 $file resulted exactly same result with gzip of oldstable (2008) and gzip of sid (2012). Picking up woody gzip and libc from archive.debian.org (2002), 33 files were not identical. This a 0.04% chance of differing file over a DECADE of changes. While evidently changes do happen, certainly not a case of whenever a butterly flaps wings in a certain direction gzip compression results change. specifics of the the test setup: 2012 sid setup, gzip 1.4-2, eglibc 2.13-20, built with gcc 4.6.1 amd64 binaries 2008 lenny setup, gzip 1.3.12-6+lenny1, glibc6 2.7-18lenny7, built with gcc 4.3, i386 binaries 2002 woody setup, gzip 1.2.4-33.1, glibc6 2.1.3-20, probably built with gcc 3.0, i386 binaries (duh) Corpus of files was all the gzip compressed files extracted and uncompressed from a partial debian mirror. All tests during the current almost full moon phase. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120210015817.ga15...@afflict.kos.to
