Your message dated Fri, 13 Nov 2015 16:43:36 +0000
with message-id <[email protected]>
and subject line Re: [Aptitude-devel] Bug#775332: aptitude: Package conflicts
are reported incorrectly
has caused the Debian Bug report #775332,
regarding aptitude: Package conflicts are reported incorrectly (without
architecture) if foreign architectures are enabled
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
775332: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775332
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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 <[email protected]>
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 (0x00007fff62cf1000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
(0x00007fdfb0c5e000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x00007fdfb0a28000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007fdfb07fd000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x00007fdfb05f7000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x00007fdfb02e1000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x00007fdfb0018000)
libboost_iostreams.so.1.55.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x00007fdfafe00000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007fdfaf9ef000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fdfaf7d1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fdfaf4c6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdfaf1c5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fdfaefae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdfaec05000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fdfaea02000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdfae7fd000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdfae5e2000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x00007fdfae3d2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fdfae1ae000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdfadfa6000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fdfadda0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdfb1647000)
-- 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.12 1.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-0c2a 2.4.0-1
ii libsqlite3-0 3.8.7.1-1
ii libstdc++6 4.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
--- End Message ---
--- Begin Message ---
Version: 0.7.4-1
Hi all,
2015-01-14 10:54 Axel Beckert:
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 <[email protected]>
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 <[email protected]>
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
p 400 spamc:i386 3.3.2-5+deb7u2 0 136 kB
p 990 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 <[email protected]>
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.
I have fixed this in 0.7.4-1 without realising that there was this bug
report about this.
spamc does not conflic with spamassassin now, but a similar example now
shows:
# aptitude show libxapian22v5 | egrep
'^(Package|Depends|Conflicts|Replaces|Provides):'
Package: libxapian22v5
Depends: libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 5.2), libuuid1
Conflicts: libxapian22, libxapian22:i386, libxapian22v5:i386
Replaces: libxapian22, libxapian22:i386
Maybe a specific marker for shown implicit conflicts due to multiarch
wouldn't be a bad idea either.
IMO this is not necessary, since the package name is the same and the
architecture a different one than the Architecture field shown in the
lines above -- it should be a very clear hint (for people who are using
multi-arch systems, at least).
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
