append default filters to hide typically-irrelevant packages from search results of the Community Repository

[davidem00]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

The top Popular items in so many search results of the Community Repository, especially the broad searches, have an overrepresentation of packages that should not be installed, anymore for various reasons. Many of the products are Obsolete, Deprecated, Broken (not just the package, but the product itself - or at least the current version - is non-functional), Discontinued, EOL, EOS, Unsafe, or otherwise abandoned in some way.

The top page of the default "All Results" search is telling. Doesn't exactly look like what one imagines a "Store" to look like, in terms of what is of interest, worth perusing. Flash, ActiveX, Win8 KB patches, an old Google Drive distribution, Silverlight, etc.

Describe The Solution. Why is it needed?

It would be good if the public package browser page applied some additional filter options, to find popular packages, find by category, but hide "irrelevant" results by (duplicates, deprecated, EOL, etc).

Default to append a set of "standard" tag filters to Community Repository web searches to filter out packages marked/tagged as Obsolete, Deprecated, Broken, Unsafe, et al from searches.

Also allow those search modifiers to be specified as user options to be appended to all repo searches via the command line.

Additional Context

The appended options should not be invisible, but explicitly appended to the terms the user gives manual, disableable by a tick box, perhaps, akin to how pre-releases are normally suppressed.

Related Issues

chocolatey/choco#3361 to provide working, multi-type criteria searches that combine tag searches (and more importantly, exclusions) with regular keyword searches.

[pauby]

Many of the products are Obsolete, Deprecated, Broken (not just the package, but the product itself - or at least the current version - is non-functional), Discontinued, EOL, EOS, Unsafe, or otherwise abandoned in some way.

Default to append a set of "standard" tag filters to Community Repository web searches to filter out packages marked/tagged as Obsolete, Deprecated, Broken, Unsafe, et al from searches.

We need to be clear on the terminology here. The Chocolatey Community Repository works with packages, not products. If a package is EOL or deprecated, it will be be reflected in the title.

packages marked/tagged as Obsolete, Deprecated, Broken, Unsafe,

There is no 'Obsolete' or 'Unsafe' status of a package. And tags are part of the package metadata set by the maintainer.

Given we don't have the statuses that you mention, and I can see no way for us to determine them from the information we have (perhaps EOL or Deprecated) and packages are not tagged by the repository itself, but maintainers, I can't see what we can implement out of this issue?

[davidem00]

I'm suggesting that these be indicated with tags, rather than separate state variables.
I would think enough of the maintainers, even if not all, would be amenable to adding some tags to the relevant packages, starting at "the top" of the Popularity list

[davidem00]

wrt the terminology, I purposely made a distinction between a package and the underlying product itself to distinguish a "broken package", i.e., the package fails to install (for most anyway), from a "broken product" where a package that installs successfully, but whose installed product is non-functional.

[pauby]

I'm suggesting that these be indicated with tags, rather than separate state variables.
I would think enough of the maintainers, even if not all, would be amenable to adding some tags to the relevant packages, starting at "the top" of the Popularity list

Encouraging maintainers to use a set of tags that haven't been defined isn't something that we are or are likely to work on. This has been talked about from time to time with repositories such as the Chocolatey Community Chocolatey Packages repository but nothing has been implemented. Even if it were, this isn't applicable to other maintainers.

wrt the terminology, I purposely made a distinction between a package and the underlying product itself to distinguish a "broken package", i.e., the package fails to install (for most anyway), from a "broken product" where a package that installs successfully, but whose installed product is non-functional.

I appreciate the distinction. The Community Repository deals with packages though, not products. A non-functional product has many definitions. If a package installs correctly, then it's a functional package.

[davidem00]

are only a limited predefined set of tags that can be used on packages, or are Maintainers free to apply any terms they see fit?

[pauby]

Tags are not predefined so maintainers can add whatever seems appropriate for their package.

[pauby]

There has been no update to this in some time, so I'm going to go ahead and close this, but we can reopen it if necessary.