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

Re: Please test gzip -9n - related to dpkg with multiarch support

On Tue, 7 Feb 2012 14:01:57 -0800
Steve Langasek <vorlon@debian.org> wrote:

> There are various ways to meet both the multiarch constraints and the policy
> requirements, including shipping an arch:all common package that will
> contain the changelog for each multiarch library, which then ships just a
> symlink.  But that's a lot of package proliferation for a fairly small
> corner case.  If we *could* ensure that the same input file produced the
> same output when compressed /with the same version of the tool/ regardless
> of architecture, that would be sufficient.  (Having to occasionally do a
> sourceful upload due to gzip version skew across architectures is certainly
> much cheaper than the alternatives.)
> 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.

OK, I admit I haven't put evidence of such digging into the bug report
currently, but it has been happening - with custom tools and upstream
co-operation. There were a few pastebin links on IRC and a private IRC
chat which I will try and summarise for the bug report tomorrow.

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.

All that the RFC requires is that an input file can be compressed
and the compressed file will *always* result in getting the original
input file back. There is nothing about the state of the compressed file
itself. It is merely an intermediary and I think we should think about
treating it as such.


Neil Williams

Attachment: pgpH6okDJQL4j.pgp
Description: PGP signature

Reply to: