I wanted to upgrade coreutils from 8.13-3.3 to 8.20-1, and
apt-listbugs didn't show any bug, but the upgrade failed:

# apt-get install coreutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  coreutils
1 upgraded, 0 newly installed, 0 to remove and 17 not upgraded.
Need to get 0 B/5,806 kB of archives.
After this operation, 399 kB disk space will be freed.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 525082 files and directories currently installed.)
Preparing to replace coreutils 8.13-3.3 (using .../coreutils_8.20-1_amd64.deb) ...
Unpacking replacement coreutils ...
dpkg: error processing /var/cache/apt/archives/coreutils_8.20-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/realpath.1.gz', which is also in package realpath 1.17
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[...]

This is reproducible, though reportbug shows:

Bugs with severity serious
    1) #687906  [powerpc] coreutils: fails to build from source (test-futimens
    2) #693211  coreutils: file conflict with realpath

I wonder whether apt-listbugs still works...

On Thu, 15 Nov 2012 09:06:53 +0100 Vincent Lefevre wrote:

[...]
[...]

Hello Vincent,
thanks for your bug report.

Bug #687906 is assigned to the coreutils *source* package and
apt-listbugs currently ignores those bugs (see #257873).

As far as I can tell, the problem is caused by the fact that the serious
bug #693211 is (correctly) assigned to both package realpath and
package coreutils.
And it is marked as found in versions realpath/1.17, coreutils/8.20-1.

Since apt-listbugs is not yet able to figure out which source package
name corresponds to a given binary package name, when it reads that
bug #693211 is found in realpath/1.17, it just drops the "realpath/"
string (as it *could* be the source package name, even though it's not,
in the present case!) and understands that the bug is found in
versions 1.17 and 8.20-1.
As a consequence, when evaluating the coreutils 8.13-3.3 -> 8.20-1
upgrade, apt-listbugs incorrectly assumes that bug #693211 is already
present in your system (the currently installed version 8.13-3.3 is
later than version 1.17 !) and therefore incorrectly thinks that
stopping the upgrade is pointless.

In case you are interested to verify this, please try

  $ apt-listbugs list coreutils/8.13-3.3 --debug

and also take a look at line 847 of
/usr/share/apt-listbugs/apt-listbugs/logic.rb


I think that this issue can only be fixed once I implement a way
to figure out the source package name of a given binary package
(as you sure know, these two names are not necessarily identical).

See also the already mentioned bug #257873 for a related (and still
unsolved, unfortunately) issue.

I will try and see whether this issue may be fixed without a major
overhaul of the code...
Anyway, please take into account that I am currently having a bunch of
personal issues: do not count on a very fast resolution. Sorry.   :-(


Note to self: maybe the source package name can be found in the
SOAP returned bug_status ("source" key). I need to investigate
further...

Hi Francesco,

My bug report was more about the second one, but thanks for the
information. Actually even if #257873 is fixed, I think that FTBFS
bugs should be filtered out by apt-listbugs; I've added a comment
about that in bug #257873.

If the real issue (get info on the source package) is difficult to
fix (so that it could take again some years), wouldn't testing both
version numbers be an acceptable workaround? I think that it is
better to get false positives (the user can easily check, and
apt-listbugs can even warn about possible false positives) than
missing false negatives.

I confirm that I get the bug with this command.

On Thu, 15 Nov 2012 23:29:49 +0100 Vincent Lefevre wrote:

[...]
[...]
[...]

The problem is exactly that apt-listbugs currently takes both "found"
versions into account (1.17 and 8.20-1), as if they were two versions
of the same package, while they instead refer to two distinct packages!

Anyway, I suppose you are no longer experiencing the problem with
bug #693211, since its version tracking info has changed in the
meanwhile...

But the issue you reported is still present in apt-listbugs and may
bite in some other cases where bugs are assigned to two (or more)
packages.
I've worked on this issue during the week-end.
I tried to implement a way to check version tracking info ("found" and
"fixed" version provided by the BTS) against source package names and
source versions, instead of binary package names and binary versions, as
explained in http://bugs.debian.org/257873#24
It (almost) works, but it's way too slow, especially when the number of
packages to be checked is large, since it has to perform one or more
SOAP communications for each package to be checked!   :-(

I really need to figure out a different approach...

On Mon, 19 Nov 2012 23:16:17 +0100 Francesco Poli wrote:

[...]

The only sane way I could think of requires a new feature in the BTS
SOAP interface. I've just opened a wishlist bug [1] to request this
enhancement for the BTS.

[1] http://bugs.debian.org/694979

I hope this may be implemented soon, so that I can modify apt-listbugs
to take advantage of it...

Bye.