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 - adejong@debian.org - http://people.debian.org/~adejong --
Attachment:
signature.asc
Description: This is a digitally signed message part