[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <vorlon@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/
slangasek@ubuntu.com                                     vorlon@debian.org


Reply to: