Re: Please test gzip -9n - related to dpkg with multiarch support
On Tue, Feb 07, 2012 at 10:13:01PM +0000, Neil Williams wrote:
> On Tue, 7 Feb 2012 14:01:57 -0800
> Steve Langasek <vorlon@debian.org> wrote:
> > At this stage, I have no reason to think that's not achievable, though no
> > one seems to have dived very deep into the bug yet. And whether gzip
> > upstream agrees this is a reasonable invariant to uphold, I don't know.
> My understanding, after a day testing this bug, is that we *cannot*
> ensure that the same input file always gives the same compressed file
> across all possible permutations. The RFC simply does not require it and
> the compression tools simply do not support it. It might be nice if they
> could but there is no real prospect that it will happen 100% of the
> time. Quite often it will work but that is coincidence and
> happen-stance. To rely on the checksums of compressed files being
> identical for all operations on the same original input file is simply
> not supportable by upstream, as I understand it currently.
The RFC doesn't require it, but as far as I see gzip doesn't use randomness,
time, uninitialised memory or anything else which might cause it ending up
with an different compression result in 1 case out of 10000. Understanding
why this happens should be the prerequisite for deciding what do about this
issue.
If it turns out not reasonable to expect the compression results to be
identical, we should probably look into using dpkg --path-exclude= with
/usr/share/{doc,man,info}/* when installing foreign-architecture packages.
Very few Multi-Arch: same packages need to install identical compressed
files outside these directories. In case it happens, the package needs to
use multiarch paths or split files to -common package. The ugliness of this
solution is that the "specialness" of /usr/share/doc and others needs to
embedded into the package system somewhere.
Riku
Reply to: