On Mon, Mar 14, 2011 at 12:10:35PM +0100, David Kalnischkies wrote:
> (sorry, no time to look closely at it currently)
Don't worry :)
> On Mon, Mar 14, 2011 at 03:15, Steve Langasek <vorlon@debian.org> wrote:
> > I've noticed what looks like a mismatch between apt's and dpkg's idea of
> > when a package is configurable, that results in apt asking dpkg to configure
> > a multi-arch: same package that isn't ready yet, and then bombing out.
> I fear its related to immediate configuration:
> Could you try with -o APT::Immediate-Configure=0 ?
> And, how tries APT to call dpkg exactly? (with/without immediate)
> -o Debug::pkgDPkgPM=1
Yes, I agree that this is probably caused by immediate configuration.
Unfortunately I can't easily rerun this to reproduce the problem, because I
encountered this in my active chroot which is now up to date. There are
only a small number of Multi-Arch: same packages in the world with which I
can test currently. :-) But I'll try your test case and see what happens.
> Attached is a small testcase for this you can drop in test/integration/ and
> run it. It should install a same package and tries to dist-upgrade then
> (in a temp directory of course).
> The output of the simulations (i have no multiarch-dpkg handy currently)
> seems to be fine as long as libsame isn't essential (i know, not allowed
> for a library in real world, but its the easiest way to get the immediate
> flag).
For a multiarch dpkg, please see dpkg 1.16.0~ubuntu4 in Ubuntu natty.
> But thinking about it, APT enables auto-deconfiguration:
> > De-configuring libstdc++6:i386 ...
> > Unpacking replacement libstdc++6 ...
> > dpkg: error processing libstdc++6 (--configure):
> > libstdc++6:amd64 4.5.2-6ubuntu1+multiarch.1 cannot be configured because libstdc++6:i386 is in a different version (4.5.2-5ubuntu3+multiarch.1)
> Looks for me like libstdc++6:i386 is deconfigured, so the (implicit) Breaks
> in libstdc++6:amd64 is satisfied and it should be configurable as the
> configuration would only be forbidden if libstdc++6:i386 would still be
> configured - but it is deconfigured currently -, doesn't it?
So I think the problem arises from this requirement of the multiarch spec:
Implementing this involves an implicit Replaces: ${self}:other (<<
${binary:Version}) in all multiarch packages. In addition, multiarch
packages are required to be kept in lockstep; i.e., an implicit Breaks:
${self}:other (!= ${binary:Version}). If more than one architecture of a
package is present on the system, this will prevent either package from
being configured unless they are all at the same version.
<https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent%20files%20in%20multiarch%20packages>
Note that this is bidirectional, by design: both the old and new packages
Break the other, which means, per policy 7.3, dpkg "will refuse to
allow the broken package to be reconfigured." So only when all the copies
of the library are updated to the same version can we again configure any of
them.
This protects us against the fact that, when upgrading *or* downgrading a
package, the implicit Replaces: between Multi-Arch: same packages mean that
the most recently unpacked package will have overwritten files belonging to
the packages of the other architectures, and there is no way for dpkg to
know with certainty which of these was unpacked most recently. So it's only
safe to declare the package "installed" again once the package is in sync
across all architectures.
I guess this part might be missing from the apt implementation, so apt
doesn't know that libc6 is actually broken until libc6:i386 is also
unpacked?
--
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
Attachment:
signature.asc
Description: Digital signature