2014-02-03 Daniel Hartwig <mand...@gmail.com>: > 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.)
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.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
