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

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

Hi Joey,

On Tue, Feb 07, 2012 at 01:07:11PM -0400, 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.

The relevant multiarch invariants are:

 - if a multiarch package is to be installed for more than one architecture,
   all architectures of the package must be at the same version

 - a file shipped at the same location by more than one architecture of the
   package must be identical across all architectures

These are reasonable constraints that spare the package manager from having
to try to arbitrate which is the "right" version of the package/file, or
distinguish between cases where the differences across architectures
"matter" vs. cases where they don't.  However, where this gets tangled is
with the one compressed file required for all packages by policy:

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.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: