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

[Daniel Hartwig]

On 3 February 2014 17:46, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2014-02-03 Daniel Hartwig <mandyke at gmail.com>:
>> 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.)
>
> Perhaps it has the intended effect then? ;-)
>

Duplicates are not desirable, even if it resolves the issue with
missing packages.  Anyway, lets just have it reverted and fixed on
wip-cmdline (weeks now, see below).

>
>> 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.
>
> When is this going to be fixed more or less?  Weeks or months?
>

I expect within two weeks.

> If it's weeks I can revert the one above and it's probably fine, the
> bug is minor and has been present since 2010 at least (feabf55d in
> 2010-04-16).
>
>
>> 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.
>
> What do you mean?  It's already fixed after I realised that the
> problem was elsewhere:
>

Right, I did not see that earlier.

> http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=1583a5b2212ed22319b3a3b6d4d4b047c34cd71c
>
> I don't know more areas where this is an issue, no.
>

Nor do I.