On Wed, Feb 08, 2012 at 09:02:43PM +0100, Guillem Jover wrote: > 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.
You are making assumption that compressor versions M, N, O, P and Q happen during a timeframe shorter than libraries are uploaded/binNMU'd in debian. Gzip development is glacial. Last upstream version changing uploads in Debian were 1.3.12 in 2007 and 1.4 in 2011. Most changes in gzip code shouldn't even affect the output of gzip -n9, as they are mostly fixes to make gzip build in world changing around it. New architectures don't happen every day, while library maintaincene does. Throwing away the "Allow identical files on Multi-Arch: same" convinience for library maintainers to make including new architectures a bit easier is a bit daft tradeoff. -- 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/20120208205724.ga7...@afflict.kos.to
