Control: tags -1 - pending On 3 February 2014 02:56, Manuel A. Fernandez Montecelo <manuel.montez...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org