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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpH6okDJQL4j.pgp
Description: PGP signature