dpkg: error: duplicate file trigger interest for filename `/usr/lib/gtk-2.0/2.10.0/immodules' and package `libgtk2.0-0:amd64'

[Steve Langasek]

On Sat, Jun 23, 2012 at 11:51:28PM +0200, Guillem Jover wrote:
> On Sat, 2012-06-23 at 13:54:33 -0700, Steve Langasek wrote:
> > On Sat, Jun 23, 2012 at 01:54:18PM +0200, Guillem Jover wrote:
> > > W/o having checked this at all, my first assumption is that this is
> > > caused by the Ubuntu specific change introduced in 1.16.3ubuntu2,
> > > which would generate duped entries for the native and foreign packages
> > > from the previous unqualified package names in the triggers database.

> > There should be no duplication of triggers here for the foreign arch.  I
> > think what's happening is that /var/lib/dpkg/triggers/File contains a
> > pre-existing line "/usr/lib/gtk-2.0/2.10.0/immodules libgtk2.0-0", and an
> > upgrade of libgtk2.0-0 after the upgrade of dpkg has now resulted in a
> > second line, "/usr/lib/gtk-2.0/2.10.0/immodules libgtk2.0-0:amd64", which
> > the change from 1.16.3ubuntu2 causes dpkg to see as a duplicate.

> > It was already my intention to canonicalize the package names on upgrade;
> > there just wasn't time to implement that before uploading 1.16.3ubuntu2,
> > which was a fix for a critical bug that would leave all amd64 desktop users
> > dead in the water.

> W/o having checked anything at all on this case, I'd say that if there's
> two entries, one for a foreign and one for a native and you always
> arch-qualify to the native then there will be duplicates. Or if there
> was a foreign unqualified entry, which gets arch-qualified to native,
> and the native instance gets installed afterwards.

No; with the previous Ubuntu dpkg, there would *already* be two entries in
the multiarch co-installation case, one for 'libgtk2.0-0' and one for
'libgtk2.0-0:i386'.  The problem when syncing up with dpkg 1.16.3 is that
the first of these was considered an error, and needed to be mapped to
libgtk2.0-0:amd64.

bsfmig's error indicates that they have at least two triggers recorded for
the *native* package, one under 'libgtk2.0-0' and the other under
'libgtk2.0-0:amd64'.  AFAICS this can only happen if libgtk2.0-0 was
upgraded after dpkg 1.16.3ubuntu2+ was installed.

> > > The correct fix would be to use the architecture from the owning
> > > package instead I guess.

> > By definition, the owning package here is always the package of the native
> > arch.  The arch qualification was added to the package spec for native-arch
> > M-A: same packages due to the mutability of the native arch (in the
> > cross-grading case), but there's no way this entry would ever have been
> > created in Ubuntu dpkg by a package other than the one dpkg considered
> > native at the time, and if there has been a cross-grade we have no record of
> > that anyway; so we should fix this up in all cases by marking this as
> > native.

> The owning package is the specific instance with the interest, which
> is depenant on the package architecture and independent of it being
> native or foreign. I guess the issue is that the Ubuntu dpkg did not
> track triggers per M-A:same instance at all, so there's no previous
> distinction of foreign arch-qualified versus native not-qualified.

No, that's not it at all.  My precise multiarch install showed the following
File triggers (among others):

  /usr/lib/gtk-2.0/2.10.0/immodules libgtk2.0-0
  /usr/lib/gtk-2.0/2.10.0/immodules libgtk2.0-0:i386

Ubuntu dpkg was already tracking triggers per M-A: same instance, it only
used a different canonicalization of the package name for the native
instance.

-- 
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 at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120623/45c84020/attachment.pgp>