On Fri, 2012-07-06 at 10:00 +0200, David Kalnischkies wrote:
> > 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):
>
> There is simple no way.
Thanks for your reply.
I guess I could drop the Provides for now then which seems to be the
least disruptive change to support multiarch (but also see below).
I can't drop the Conflicts because libnss-ldapd and libnss-ldap share
the same file (at least the same library which may be in the same file
depending on whether you are comparing multiarch or non-multiarch
versions).
> > # 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
>
> Which dpkg version is that?
This was 1.16.4.2 that was lying around in a play chroot. dpkg 1.16.7
installs the deb just fine.
I've been playing a bit with only changing the conflicts to include
:${Arch} which seems to work with dpkg (though lintian still complains),
however apt doesn't seem to understand it and doesn't remove
libnss-ldapd when installing libnss-ldap.
Then again, I can't reproduce the problem that Thorsten reported. I've
got both libnss-ldapd:i386 and libnss-ldapd:amd64 installed (both
0.8.10-1) in a chroot with dpkg:i386 1.16.7. The installation was done
with apt-get (apt:i386 0.9.7.1) and went fine. Also apt-get dist-upgrade
doesn't want to remove either of the packages (for some reason apt does
want to switch back to the i386 coreutils that I managed to switch to
amd64).
On Fri, 2012-07-06 at 11:02 +0000, Thorsten Glaser wrote:
> Could this work: libnss-ldap and libnss-ldapd both provide the same
> virtual package and conflict with it? Same for the pam ones but a
> different virtual package.
My guess is that it wouldn't because the conflict would still match it
on the other architecture.
--
-- arthur - adejong@debian.org - http://people.debian.org/~adejong --
Attachment:
signature.asc
Description: This is a digitally signed message part