Support alternative dependency

[stevapple]

Description of the new feature / enhancement

Some of the packages are known to be conflicted (eg. Microsoft.VC++2015-2022Redist-x64 and Microsoft.VC++2015-2019Redist-x64), but we can only specify one of them in the manifest, and users with another installed cannot successfully upgrade or install our package.

Proposed technical implementation details

We have several means of resolving this:

• One is to let the library specify its possible alternatives in its manifest, so Microsoft.VC++2015-2019Redist-x64 can indicate that it's replaceable by Microsoft.VC++2015-2022Redist-x64. When the user try to install a package that depends on Microsoft.VC++2015-2019Redist-x64, winget scans if any of the alternatives is installed, and skip installing Microsoft.VC++2015-2019Redist-x64 accordingly.
• A slightly different way is to let the package specify the package it can replace, so Microsoft.VC++2015-2022Redist-x64 can indicate that it's capable of replacing Microsoft.VC++2015-2019Redist-x64. winget will regard Microsoft.VC++2015-2019Redist-x64 as installed as long as Microsoft.VC++2015-2022Redist-x64 is installed.
• The safest solution is let the dependent application to specify a list of alternative. When the application is being installed, winget will check the alternatives besides the default dependency. If none of them is installed, winget will kick off installing the default one.

[jedieaston]

Do you think that the proposal in #1789 would resolve this problem? Several packages that each would satisfy the same dependency.

[stevapple]

@jedieaston I think that’s almost the third option I proposed — but I believe there should be a primary (in other word, recommended) one, which winget will pick up when neither of the alternatives matches.

[denelon]

We've been discussing the best way to handle determining which of a collection of dependencies to install if none are present. One of our goals is to support unattended "import" scenarios. This scenario is one of the more complex ones due to dependencies like language runtimes that may have different licensing concerns.

[stevapple]

My preferred manifest layout would be:

# ...
Dependencies:
  PackageDependencies:
  - PackageIdentifier: Microsoft.VC++2013Redist-x64
    MinimumVersion: 12.0.30501.0
  - PackageIdentifier: Microsoft.VC++2013Redist-x86
    MinimumVersion: 12.0.30501.0
  - PackageIdentifier: Microsoft.VisualStudio.2019.Community
    MinimumVersion: 16.11.0
    Alternatives:
    - PackageIdentifier: Microsoft.VisualStudio.2019.Professional
      MinimumVersion: 16.11.0
    - PackageIdentifier: Microsoft.VisualStudio.2019.Enterprise
      MinimumVersion: 16.11.0
    - PackageIdentifier: Microsoft.VisualStudio.2022.Community
    - PackageIdentifier: Microsoft.VisualStudio.2022.Professional
    - PackageIdentifier: Microsoft.VisualStudio.2022.Enterprise

The easiest way is to let the application vendor decide the recommended option, which some of them are already doing in official documents or installation guides. In my scenario this just works. However, I do understand that there could be more complicated needs (license for example).

[Trenly]

[Policy] Dependencies