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, 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.
> > 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.
But again I'm quite tired now, and I've not checked any detail of this
specific situation...
regards,
guillem
Reply to: