review: give examples of how to search for alternatives

[slyon]

In the [Duplication] section for MIR review add:

RULE: Duplicates can be found by searching packages in "main", e.g. using:
RULE: $ apt list "?not(?section(/))" | grep <SEARCH_TERM>
RULE: and/or by checking for alternatives on https://www.libhunt.com/ or
RULE: similar databases.

[cpaelzer]

Was apt-cache search intended here? The output of apt list "?not(?section(/))" on my systems doesn't have any of the english descriptions and didn't seem very useful for grepping.

I was thinking the same, I mean the suggested info isn't bad - it just isn't complete enough. It will find direct hits and it will do that great. But to go further I'm usually also going for apt-cache search <SEARCH_TERM> and hunt for things in there. How about adding (not replacing) to yours by the following

RULE: Sometimes duplicates are not too obvious, but can often be found by searching through
RULE: full descriptions, provides and all that. If the above check didn't already find a duplicate
RULE: then this check can be done via the following steps:
RULE:   $ apt-cache search  <SEARCH_TERM>
RULE: In the returned list pick anything that looks suspicious and check if any is in main.
RULE:   $ apt-cache policy <all, packages, that, look, like, duplicate, functionality>
RULE: If any of them are reported to be in main check in detail if they cover indeed the same.

[slyon]

Thanks for your suggestions, I've extended this RULES section accordingly.

The idea of apt list "?not(?section(/))" was to search the "main" component only. After discussions with juliank there's unfortunately no way to search descriptions of packages in "main" only; so it's only direct matches. Using apt-cache search and checking the component manually is good to note here, too.

PTAL.

[cpaelzer]

Thank you, IMHO that is now good to land and helpful to new reviewers (and to remind old ones). I'll do minimal follow up that isn't worth a new iteration of review.