Define deterministic package resolution across multiple sources

[denelon]

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

WinGet needs a consistent package-resolution model for commands that can receive candidates from multiple sources.

Several existing issues describe related symptoms:

• equivalent packages appear more than once
• source-specific results may not consistently enforce the user's requested filters
• exact or combined filters can still produce unexpected results
• source priority affects ordering and selection but remains experimental
• multiple valid candidates require the user to refine and rerun the command
• REST sources such as msstore can return results that are insufficiently correlated with the original query
• installed-package commands may select a package from a different source than the one associated with the installed package

These behaviors should be considered together so package selection is deterministic, explainable, and consistent across applicable commands.

Proposed technical implementation details

Define candidate eligibility

Establish which results from each source are eligible for selection based on the user-supplied query fields and filters.

REST source results should be locally evaluated when necessary to ensure they satisfy the requested name, identifier, moniker, exact-match, and other filters.

Candidate eligibility should use simple, explicit rules rather than a complex cross-source scoring mechanism.

Define source-priority behavior

Source priority should remain a hard boundary after candidate eligibility has been determined.

Only the highest-priority source or sources containing eligible results should participate in the remaining resolution process. Lower-priority sources should not participate once eligible results exist at a higher priority.

An explicit --source argument should constrain the applicable sources before priority is evaluated.

This work should also determine whether the current source-priority implementation is ready to become non-experimental and how WinGet explains a priority-based selection to the user.

Define package equivalence across sources

When every source at the highest applicable priority has exactly one eligible result, determine whether entries from those sources represent the same package and may be correlated for resolution or display.

Potential signals include:

• package identifier
• package name and publisher
• installer identity
• installer SHA256
• product codes or package family names
• source-provided correlation metadata

No single signal should be assumed sufficient for every installer type or package scenario.

Correlation should not be used to score candidates or resolve multiple results returned by an individual source.

Improve unresolved ambiguity

When multiple eligible candidates remain:

• interactive sessions should allow the user to select from the valid candidates
• non-interactive sessions should fail without making an arbitrary selection
• failure output should provide the exact --id, --exact, --source, or other arguments needed to disambiguate the command

The applicable behavior should be defined for install, show, upgrade, and uninstall.

For installed-package operations, the set of applicable sources may first need to be constrained by the source associated with the installed package. That behavior is tracked by #4347.

Proposed resolution model

The final design should use a simple, predictable sequence equivalent to:

1. Collect candidates from the applicable sources.
2. Enforce all user-supplied filters and reject ineligible results.
3. Consider only the highest-priority source or sources that contain eligible results.
4. If every source at that priority has exactly one result, correlate equivalent packages across those sources where identity can be established.
5. Select the single remaining candidate, prompt interactively, or return actionable disambiguation guidance.

Lower-priority sources do not participate once an eligible higher-priority source has been identified. Package correlation is not a scoring mechanism and should not override ambiguity within a source.

Success criteria

• The same inputs, source configuration, and priority configuration produce a deterministic result.
• All user-supplied filters are enforced before source priority is applied.
• Lower-priority sources do not affect selection when a higher-priority source has eligible results.
• Equivalent packages do not cause unnecessary ambiguity when their identity can be established safely.
• Multiple results within a source are not silently resolved through cross-source correlation.
• Source-priority decisions are predictable and visible to the user.
• Interactive and non-interactive behavior are explicitly defined.
• Installed-package operations account for the source associated with the installed package.
• Diagnostic output explains why WinGet selected a package or requires disambiguation.

Open design questions

• What local validation is required to determine whether REST source results satisfy each user-supplied filter?
• How should sources with the same configured priority be represented and processed?
• Which signals establish that packages from different sources are equivalent?
• Should equivalence be used only for resolution, or should results also be visually coalesced?
• How should packages with the same installer but different metadata or servicing behavior be treated?
• How should installed-package source information constrain upgrade and uninstall resolution?
• What information should be shown when WinGet makes a source-priority selection?
• Which commands can share the same resolution pipeline, and where do installed-package semantics require different behavior?
• Should interactive selection be enabled by default, configurable, or limited to particular commands?

Search-result sorting and presentation are related but distinct from package identity and command resolution:

• Change default sort order on search. #142
• [New Feature]: Customizable sorting for search output #1769

Interactive selection and non-interactive disambiguation are tracked by #301. That issue is already a sub-issue of #6398, so it remains linked as a related dependency rather than being assigned a second parent.

Historical behavior for identical package identifiers across multiple sources was reported in #840.

[github-actions]

Possible duplicate(s):

Thank you for submitting this issue.

The issue(s) below may already track your request or bug. Please take a look — if one of them matches, give that issue a 👍 and close this one as a duplicate. Older or curated issues are preferred as the canonical one to follow.

• Packages with the same ID and name in multiple repos break "winget show" and "winget install"  #840 — Packages with the same ID and name in multiple repos causing winget show/install to fail even with --exact --id, and the need to show source information and disambiguate
• upgrade and uninstall commands default to using msstore instead of respecting the package source that the package was originally installed from #4347 — upgrade and uninstall defaulting to msstore instead of the source the package was originally installed from, a core source-priority resolution issue
• It is difficult to get the app I want if they have the same / similar names. #301 — Interactive numbered selection vs. fail-fast behavior when multiple packages match, including actionable --id --exact --source disambiguation guidance for non-interactive sessions

Template: msftbot/duplicate/surfaced by Duplicate Surfacing

[JohnMcPMS]

Priority as it is currently written is a hard line. This suggests changing it to be a tie-breaker instead. I don't think having a complex scoring mechanism is good here, we want a simple set of rules that can lead to predictable results.

Steps as I see it:

1. Collect candidates from the applicable sources.
2. Enforce all user-supplied filters [which is "Reject results that do not meet the required match criteria."]
3. For each source at the highest priority with results, IFF there is only one result per source, continue. Otherwise, goto 5.
4. Correlate equivalent packages across sources where identity can be established.
5. Select the single remaining candidate, prompt interactively, or return actionable disambiguation guidance.