Bug#775332: [Aptitude-devel] Bug#775332: Bug#775332: aptitude: Package conflicts are reported incorrectly
On Wed, Jan 14, 2015 at 11:54:48AM +0100, Axel Beckert wrote: Keith Edmunds wrote: I didn't expect it to list a conflict with spamassassin twice, nor did I expect it to conflict with itself. There are actually valid situations for both, the later is e.g. explicitly allowed by debian-policy as a to be ignored self-conflict, but takes effect on packages providing this name… The interactive text mode interface (TUI) shows why this happens: --\ Conflicts (3) --\ spamassassin ( 2.30-2) --\ spamassassin ( 2.30-2) --\ spamc p400 spamc:i386 3.3.2-5+deb7u2 0 136 kB p990 spamc:i386 3.4.0-5 0 150 kB The shown conflict is an implicit one: spamc has no Multiarch header, which implies Multiarch: none which again implies that it can't be installed together with spamc from another architecture. Aptitude seems to show these implicit conflicts like explicit ones. If this is a good or bad thing is probably debatable. (Indeed. Note that apt-cache does both: It doesn't show them in 'show', while it does in 'depends'. It all heavily depends on what is expected and both can be valid.) The duplicated spamassassin conflict can be explained that way, too: It probably duplicated it for each architecture, but doesn't show the architecture at that point. That is in fact the correct explanation as it is how libapt is translating multi-arch into the previously known single-arch. This way our 'old' tools kept working without major changes. IMHO the output of aptitude in your case should have been similar to this: Package: spamc State: not installed Version: 3.4.0-5 Priority: optional Section: mail Maintainer: Noah Meyerhans no...@debian.org Architecture: amd64 Uncompressed Size: 186 k Depends: libc6 (= 2.14), libssl1.0.0 (= 1.0.0), zlib1g (= 1:1.1.4) Suggests: spamassassin Conflicts: spamassassin ( 2.30-2) [amd64], spamassassin ( 2.30-2) [i386], spamc [i386] This should be spamc:i386 and similar as this is the way architecture- dependent dependencies are specified. In code, its probably something along the lines of changing .Name() to .FullName(true). Note that architecture-dependent dependencies are a thing now, so you probably have to solve this either way, regardless of how you resolve this one (assuming its a problem, I haven't checked). Maybe a specific marker for shown implicit conflicts due to multiarch wouldn't be a bad idea either. Note that a dependency iterator has the method IsMultiArchImplicit() to check if they are implicit or not in case you want to handle them differently (and note that this also effects breaks and replaces). btw: Provides can be implicit, too (see M-A: foreign). Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#775332: aptitude: Package conflicts are reported incorrectly
Package: aptitude Version: 0.6.11-1+b1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I wanted to check what packages 'spamc' would pull in. * What exactly did you do (or not do) that was effective (or ineffective)? I ran aptitude show spamc * What was the outcome of this action? This (partial) output: $ aptitude show spamc Package: spamc State: not installed Version: 3.4.0-5 Priority: optional Section: mail Maintainer: Noah Meyerhans no...@debian.org Architecture: amd64 Uncompressed Size: 186 k Depends: libc6 (= 2.14), libssl1.0.0 (= 1.0.0), zlib1g (= 1:1.1.4) Suggests: spamassassin Conflicts: spamassassin ( 2.30-2), spamassassin ( 2.30-2), spamc * What outcome did you expect instead? I didn't expect it to list a conflict with spamassassin twice, nor did I expect it to conflict with itself. Note this does not appear to be a problem with the spamc package as the output from apt-cache seems sane: $ apt-cache show spamc|grep ^Conflicts Conflicts: spamassassin ( 2.30-2) -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.4.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140913 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7fff62cf1000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7fdfb0c5e000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fdfb0a28000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fdfb07fd000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fdfb05f7000) libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fdfb02e1000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fdfb0018000) libboost_iostreams.so.1.55.0 = /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7fdfafe0) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7fdfaf9ef000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fdfaf7d1000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fdfaf4c6000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fdfaf1c5000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fdfaefae000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fdfaec05000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fdfaea02000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdfae7fd000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fdfae5e2000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fdfae3d2000) liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fdfae1ae000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fdfadfa6000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fdfadda) /lib64/ld-linux-x86-64.so.2 (0x7fdfb1647000) -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.121.0.9.5 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-13 ii libcwidget3 0.5.17-2 ii libgcc1 1:4.9.1-19 ii libncursesw5 5.9+20140913-1+b1 ii libsigc++-2.0-0c2a2.4.0-1 ii libsqlite3-0 3.8.7.1-1 ii libstdc++64.9.1-19 ii libtinfo5 5.9+20140913-1+b1 ii libxapian22 1.2.19-1 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc] 0.6.11-1 ii libparse-debianchangelog-perl 1.2.0-1.1 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index none pn debtags none ii tasksel 3.29 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775332: [Aptitude-devel] Bug#775332: aptitude: Package conflicts are reported incorrectly
Control: tag -1 + confirmed Control: retitle -1 aptitude: Package conflicts are reported incorrectly (without architecture) if foreign architectures are enabled Hi, Keith Edmunds wrote: I ran aptitude show spamc * What was the outcome of this action? This (partial) output: $ aptitude show spamc Package: spamc State: not installed Version: 3.4.0-5 Priority: optional Section: mail Maintainer: Noah Meyerhans no...@debian.org Architecture: amd64 Uncompressed Size: 186 k Depends: libc6 (= 2.14), libssl1.0.0 (= 1.0.0), zlib1g (= 1:1.1.4) Suggests: spamassassin Conflicts: spamassassin ( 2.30-2), spamassassin ( 2.30-2), spamc * What outcome did you expect instead? I didn't expect it to list a conflict with spamassassin twice, nor did I expect it to conflict with itself. [...] Architecture: amd64 (x86_64) Foreign Architectures: i386 Indeed. I can reproduce it on an amd64 box with i386 as foreign architecture, but not on a machine which doesn't have any foreign architectures enabled. There it looks as expercted: ~ → aptitude show spamc Package: spamc State: not installed Version: 3.4.0-5 Priority: optional Section: mail Maintainer: Noah Meyerhans no...@debian.org Architecture: i386 Uncompressed Size: 150 k Depends: libc6 (= 2.7), libssl1.0.0 (= 1.0.0), zlib1g (= 1:1.1.4) Suggests: spamassassin Conflicts: spamassassin ( 2.30-2) […] The interactive text mode interface (TUI) shows why this happens: --\ Conflicts (3) --\ spamassassin ( 2.30-2) --\ spamassassin ( 2.30-2) --\ spamc p400 spamc:i386 3.3.2-5+deb7u2 0 136 kB p990 spamc:i386 3.4.0-5 0 150 kB The shown conflict is an implicit one: spamc has no Multiarch header, which implies Multiarch: none which again implies that it can't be installed together with spamc from another architecture. Aptitude seems to show these implicit conflicts like explicit ones. If this is a good or bad thing is probably debatable. The duplicated spamassassin conflict can be explained that way, too: It probably duplicated it for each architecture, but doesn't show the architecture at that point. IMHO the output of aptitude in your case should have been similar to this: Package: spamc State: not installed Version: 3.4.0-5 Priority: optional Section: mail Maintainer: Noah Meyerhans no...@debian.org Architecture: amd64 Uncompressed Size: 186 k Depends: libc6 (= 2.14), libssl1.0.0 (= 1.0.0), zlib1g (= 1:1.1.4) Suggests: spamassassin Conflicts: spamassassin ( 2.30-2) [amd64], spamassassin ( 2.30-2) [i386], spamc [i386] That way the source of these conflicts would have been much clearer. Maybe a specific marker for shown implicit conflicts due to multiarch wouldn't be a bad idea either. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
