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).
MfG
Goswin
Reply to: