Description of the new feature / enhancement

• Related to Support for "or" dependencies. #1789
• Related to Support alternative dependency #2103

The need for "Or" dependencies, sometimes referred to as "One of" or "Any of" has been highlighted before. There are many cases where Package C is dependent on Package A or Package B.

There is another use case where Package C may require something which could be provided by a number of different packages - some which may be unknown to winget or possibly not yet created. A great example of this are packages which require a JRE to be installed. There is the official JRE from Oracle, but there are also many different versions supplied through other vendors, any of which may satisfy the requirement of having a JRE. If a new package is added in the future which also satisfies the requirement of providing a JRE, all manifests using the "One of" dependency style will require updating to include the new package. This necessitates having a way to dynamically specify categories of dependency independent of specific package identifiers.

Proposed technical implementation details

To accomplish this, two new manifest fields could be added under dependencies (or some other way, whatever works)

Dependencies:
  Providers:
     - <From Enum>
  Provides:
     - <From Enum>

Providers would be any group of dependencies which have so many potentially applicable identifiers that it does not make sense to list them individually. Some examples would include LaTex, JRE, JDK, maybe even VSCode (given all the knock offs and customized versions).

The list of Providers and associated Package IDs would need to be available in the PreIndexed source and REST source. This will allow for checking if a provider dependency has been met.

If a user attempts to install a package which is dependent upon Provider A, any PackageID which declares itself as Provides A shall satisfy the dependency.

Usage of Provides in the community repository should throw a validation warning, requiring manual review from Microsoft before being merged. If waivers are used, they should apply only to existing Provides such that if a new value is added, manual validation will be triggered again. Additionally, removal of Provides shall require manual review. If version 3 of the package declares the package as a provider, version 4 must also declare the provides; however, it would be acceptable if version 1 and 2 did not. Given the complexity around dependencies and ensuring accurate providers, it would be best not to use waivers at all for the initial release.