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@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature