found 680226 0.8.5 tags 680226 + help thanks On Wed, 2012-07-04 at 15:42 +0200, Thorsten Glaser wrote: > this situation is a bit weird, on an M-A enabled system (debugging > hindered a bit due to #680225), after upgrading libnss-ldapd and > libpam-ldapd to the latest version (or even before doing that), a > further dist-upgrade wants to kill them and install libnss-ldap and > libpam-ldap (the nōn-“d” versions, which thus will not work due to > #423252) from i386 (WTF?).
Thanks for pointing this out. My guess is that this is due to the Conflicts/Replaces that is included in libnss-ldapd on libnss-ldap and in libpam-ldapd on libpam-ldap. I guess the conflicts is interpreted to apply to any installed version of the package while what should be interpreted as a conflict/replaces only of the package of the same architecture. I'm not sure what the proper way is to specify that Conflicts and Provides should only apply for a same-architecture version of the package. If I do this (just trying some things): Conflicts: libnss-ldap:${Arch} Provides: libnss-ldap:${Arch} the package is built but Lintian complains loudly and dpkg refuses to install with: # dpkg -i libnss-ldapd_0.8.10-2_i386.deb dpkg: error processing libnss-ldapd_0.8.10-2_i386.deb (--install): parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package 'libnss-ldapd': 'Conflicts' field, reference to 'libnss-ldap': invalid architecture name 'i386': a value different from 'any' is currently not allowed This page [https://wiki.ubuntu.com/MultiarchSpec] says: "consideration of a syntax extension for Conflicts(and Replaces) is deferred until after the initial implementation" Does anyone know how to deal with this situation? I could perhaps drop the provides (or make it Provides: libnss-ldap:${Arch}). There is only one package in the archive that has a suggests on libnss-ldap so the "damage" within the archive should be minimal. This would only leave the case where you would want to have libnss-ldap on i386 and libnss-ldapd on amd64 impossible (which is theoretically valid). Any ideas? -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part