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

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

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

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

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

Reply to: