[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, Feb 07, 2012 at 10:04:04PM +0000, Neil Williams wrote:
> On Tue, 07 Feb 2012 19:11:16 +0100
> Michael Biebl <biebl@debian.org> wrote:
> > On 07.02.2012 18:07, Joey Hess wrote:
> > > Neil Williams wrote:
> > >> I'd like to ask for some help with a bug which is tripping up my tests
> > >> with the multiarch-aware dpkg from experimental - #647522 -
> > >> non-deterministic behaviour of gzip -9n.
> > > 
> > > pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required
> > > to always produce the same compressed file for a given input file, and I
> > > can tell you from experience that there is a wide amount of variation. If
> > > multiarch requires this, then its design is at worst broken, and at
> > > best, there will be a lot of coordination pain every time there is a
> > > new/different version of any of these that happens to compress slightly
> > > differently.
> Exactly. I'm not convinced that this is fixable at the gzip level, nor
> is it likely to be fixable by the trauma of changing from gzip to
> something else. That would be pointless.
> What matters, to me, is that package installations do not fail
> somewhere down the dependency chain in ways which are difficult to fix.
> Compression is used to save space, not to provide unique identification
> of file contents. As it is now clear that the compression is getting in
> the way of dealing with files which are (in terms of their actual
> *usable* content) identical, then the compression needs to be taken out
> of the comparison operation. Where the checksum matches that's all well
> and good (problems with md5sum collisions aside), where it does not
> match then dpkg cannot deem that the files conflict without creating a
> checksum based on the decompressed content of the two files.

But it's worse than this: even if dpkg decompresses before comparing,
debsums won't (and mustn't, for backward compatibility).  So it's
potentially necessary to fix up the md5sums file for a package
installed for multiple architectures, if it contains a file that was
compressed differently.


Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus

Reply to: