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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgphW4GEeQUJw.pgp
Description: PGP signature