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

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

On Wed, 8 Feb 2012 15:06:46 +0100
Adam Borowski <kilobyte@angband.pl> wrote:

> 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
> * after a bugfix (including security ones)
> * on a different architecture
> * with different optimizations
> * with a different implementation (like those parallel ones)
> * possibly with a different moon phase
> 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.

I don't get it. That would only affect packages which were built during
the time that a new upload of gzip is made and all the buildd's making
that new version available. Now, if there is a binNMU after a new
version of gzip is uploaded, yes it is probably wise to rebuild all
architectures if the package includes a Multi-Arch: same library. How
often does that happen?

It doesn't matter for other packages in the archive - it only matters
for binary packages of the same Multi-Arch source which can install the
same file in the same place from two or more architectures.

Binaries in the archive already are completely unaffected by a new gzip
- the only collision is between compressed files in the same location
under /usr/share/doc and Policy already handles that with the exception
of problems inherent to Multi-Arch. 

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

However, having said all that, I think that an approach which borrows /
inherits from existing dpkg-cross behaviour by simply assuming that
anything in /usr/share of a Multi-Arch: same package just doesn't
matter for the functionality of the package is much better, much more
reliable allowing any collisions to just get silently ignored.

It avoids all of the gzip problems and the only remaining collisions
can be fixed as bugs.


Neil Williams

Attachment: pgphW4GEeQUJw.pgp
Description: PGP signature

Reply to: