Re: Summary: dpkg shared / reference counted files and version match
On Fri, Feb 10, 2012 at 05:35:19PM -0800, Russ Allbery wrote:
> Steve Langasek <firstname.lastname@example.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
- 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
- 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
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
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/