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

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

Adam Borowski <kilobyte@angband.pl> writes:

> On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
>> For those not subscribed to that bug, how to reproduce[1] and possible
>> fix[2] are available now. There might be other places where buffers are
>> reused, I only spent a few minutes on this during my lunch break.
>>  2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522
> Even if you ensure a particular build behaves exactly the same on a given
> architecture, you're merely introducing future problems.
> gzip's output is likely to change:
> * on a new version

Yes, but not a big problem (other than a small race condition) since all
buildds should have the same version.

> * after a bugfix (including security ones)

Yes, but not a problem (other than a small race condition) since all
buildds should have the same version.

> * on a different architecture

No. I consider that a bug.

> * with different optimizations

Not a problem.

> * with a different implementation (like those parallel ones)

Not a problem (yet). We only have one gzip. pigz doesn't replace gzip.

> * possibly with a different moon phase

No. I consider that a bug.

> 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.

Not true. Packages only break if they are build with one gzip on one
arch and another on other archs. On gzip uploads there is a window where
archs will have different gzip versions so this is of some concern. But
not as bad as you make it look.

> Breaking the ideas for diverting /bin/gzip by pigz is not nice, too.

True. But why should gzip and pigz give different output? They should be
able to result in the same compressed output.

I think for pigz one problem is where to split the input. Making it
split at the same points as gzip --rsyncable does (and using that option
in gzip) could be a solution.

Or files in /usr/share/doc (where we have the collisions) could be
compressed with /usr/bin/gzip.gzip (assuming that would be the name of
the real binary providing the gzip alternative).


Reply to: