On Wed, 2012-02-08 at 11:25:28 -0800, Don Armstrong wrote: > On Wed, 08 Feb 2012, Neil Williams wrote: > > 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? > > Isn't this something that we can test for in the archive, and require > rebuilds for all affected packages before entering testing? > [Multi-Arch: same with the same path that have differing md5sums?]
This has for example the following implication: Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to sid generating a reproducible output across all current architectures. Time passes, compressor version N (and even O and P and Q etc) gets uploaded, which starts producing new ouput (on each of those versions). A new architecture gets added to Debian, and because previous compressor versions are not in the archive anymore, all packages built with them have different checksums than the new ones. This means *all* those packages have to be binNMUed across *all* the architectures, or the porters need to hunt down every specific compressor version used to build those packages to be able to reproduce the build on their arch. This seems highly suboptimal and “future-unproof”... regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120208200243.ga29...@gaara.hadrons.org
