[Aptitude-devel] Bug#720750: aptitude: search returns different numbers of packages depending on sort order

[Daniel Hartwig]

Control: tags -1 - pending

On 3 February 2014 02:56, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> Control: tags -1 + pending
>
> Fix commited, it will be included in the next release if no problem is
> found with the fix.
>
> http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491
>

> +
> +    /* mafm: Disabled because it does not respect the 3 way comparison of the
> +     * sort policies, so it removes from the result set any items with the same
> +     * result for the given policy (package_results_eq with successful result,
> +     * which means comparison result zero in policy).
> +     *
> +     * This is usually not noticeable in names (should be unique) or sizes of
> +     * packages (very rare that the size is the same); but it does not work well
> +     * on versions (repeated sometimes) and specially not in priorities, since
> +     * they are only a few of them for all of the packages in the archive.
> +
>      output.erase(std::unique(output.begin(), output.end(),
>                               aptitude::cmdline::package_results_eq(sort_policy)),
>                   output.end());
> +    */

The search results will now include duplicate packages where there are
multiple search patterns matching the same package:

$ ./aptitude search '?name(^emacs24)' '?name(^emacs24)'
p   emacs24                         - GNU Emacs editor (with GTK+ user interface
p   emacs24                         - GNU Emacs editor (with GTK+ user interface
[...]

(That example is obviously contrived, but it is quite common for
multiple patterns to have overlapping matches.)

It is package_results_eq that must be corrected to properly address
this.  That function should consider package equality, rather than
equality in sort_policy.

Please revert.  Note that package_results_eq no longer exists after
wip-cmdline as search results are collected in a pkgset [libapt] which
guarantees to contain only unique packages.  Likewise for versions using
verset.

If you like, feel free to submit a patch for consideration that
addresses the issue in package_results_eq.  Though, as I mentioned, this
will otherwise be resolved by the pending merge of wip-cmdline.


Also related to this is the earlier addition of installsizechange.  This
is a 2-way comparison, inconsistent with the rest of the sorting module
which is 3-way.  There is this comment:

> +                       // mafm: if returning zero, the comparison stops for
> +                       // other packages

Clearly this refers to bug #720750.  Are there other areas you know
about where this is an issue?  If there are, we can fix those instead of
hacking around them in the sorting module.

Sorting module presently relies on 3-way comparisons for functionality
such as chaining (as with a sort policy of "priority, name").  At
present, installsizechange will fail to chain correctly and this should
be corrected.


Regards