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

[Manuel A. Fernandez Montecelo]

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? ;-)


> 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?

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:

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.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>