On 3 February 2014 17:46, Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: > 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? ;-) >
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
