On Fri, Feb 10, 2012 at 05:35:19PM -0800, Russ Allbery wrote: > Steve Langasek <vor...@debian.org> writes: > > On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote:
> >> I agree that the extra work of removing "multi-arch: same" for existing > >> -dev packages that have been converted is a major downside. And on the > >> other hand, the need throughout Debian infrastructure to support the > >> very fragile refcount approach would be a downside to that approach. > > Which infrastructure do you have in mind? I don't see anything that's > > needed besides a dpkg implementation (which we have) and some tools to > > sanity-check coinstallability (which 1. we would need anyway, and 2. we > > also have a preliminary implementation of). > We need a guarantee that gzip will always produce the same output, which > we already know isn't the case and which doesn't look sustainable going > forward. That's looking rather uncomfortable. The preliminary results > there point to that being somewhat problematic. I guess we're looking at the same data, yet we seem to have reached opposite conclusions. - Riku reports that 33 out of 82k files have different compression when using current gzip vs. 10-year-old gzip. I'd be surprised if any of those binary packages hadn't been superseded long ago. It's not a guarantee, but I think the risks, and ultimate cost, of relying on gzip output to not change often and to just do sourceful rebuilds when it isn't are a lot smaller than if we go about manually splitting our packages further. - The cases where gzip output has been reported to not be reproducible seem to all boil down to a single issue with gzip being passed different arguments due to the unreproducible nature of *find*'s output. A patch has been made available already on the bug, and this patch seems to address the instances of the problem that we've hit so far in the Ubuntu archive. Now, it's worth following up with gzip upstream about our concerns, but even without that, I just don't see this being problematic. > I think we have to do something saner with changelog files eventually > regardless, but I'm curious: how did Ubuntu deal with the binNMU problem > that Guillem identified? If you binNMU a library on amd64 but not on > i386, as near as I can tell that's going to make the library not work for > multiarch until the next sourceful upload, no? I think Ubuntu has > binNMUs; haven't you run into this issue? Ubuntu deals with this problem by never having supported binNMUs. ;) This is a recognized flaw in Launchpad that folks want to address, but it does mean that this wasn't a blocker for ramping up multiarch there. But there have been discussions with the Debian buildd admins about how to solve this, with a reasonable consensus for splitting the binNMU changelogs into architecture-specific files. -- 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/ slanga...@ubuntu.com vor...@debian.org -- 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/20120211185237.ga10...@virgil.dodds.net