Winget says package is already installed, when it isn't

[anthonyvdotbe]

Brief description of your issue

2 flavors of FFmpeg cannot be installed alongside each other, but the error message doesn't make sense and is confusing.

Steps to reproduce

• winget install --id 'Gyan.FFmpeg' --scope machine
• winget install --id 'Gyan.FFmpeg.Shared' --scope machine

Expected behavior

Either both packages install, or the second command explains that Gyan.FFmpeg.Shared cannot be installed alongside Gyan.FFmpeg (ideally, it would also explain that Gyan.FFmpeg.Shared is a superset of Gyan.FFmpeg, and propose to uninstall Gyan.FFmpeg automatically before installing Gyan.FFmpeg.Shared).

Actual behavior

The second command just says the package is already installed, which is not true and confusing. What's particularly problematic to me, is that the commands use IDs, so it doesn't make sense to me that 2 packages with different IDs cause this behavior.

Environment

Windows Package Manager v1.6.3133
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.2715
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.3133.0

[denelon]

Are there any difference in Windows Apps & Feature via settings between how these two applications appear when they are installed?

[anthonyvdotbe]

Yes. Gyan.FFmpeg.Shared:

and Gyan.FFmpeg:

[denelon]

I see what's happening. The part in parenthesis is generally ignored. This is often a mechanism used to indicate scope or architecture but hasn't been reliable enough to use as authoritative since it's just a "displayName" field.

WinGet would see both entries as the same package. It may be possible to add Apps and Features entries to the manifests to clearly differentiate the "displayName" properties. We've been discussing changing the default logic to include what is in parenthesis when the Apps and Features entries are present in the manifest.

[denelon]

We've been working on the side-by-side scenarios. You could try the latest release and enable the experimental feature on:

• https://github.com/microsoft/winget-cli/releases/tag/v1.8.924-preview

Please provide feedback at:

• Side by Side Experimental Feature Feedback #4281

[anthonyvdotbe]

Yes. Gyan.FFmpeg.Shared:

and Gyan.FFmpeg:

[denelon]

I see what's happening. The part in parenthesis is generally ignored. This is often a mechanism used to indicate scope or architecture but hasn't been reliable enough to use as authoritative since it's just a "displayName" field.

WinGet would see both entries as the same package. It may be possible to add Apps and Features entries to the manifests to clearly differentiate the "displayName" properties. We've been discussing changing the default logic to include what is in parenthesis when the Apps and Features entries are present in the manifest.

[denelon]

We've been working on the side-by-side scenarios. You could try the latest release and enable the experimental feature on:

• https://github.com/microsoft/winget-cli/releases/tag/v1.8.924-preview

Please provide feedback at:

• Side by Side Experimental Feature Feedback #4281

[denelon]

Is this problem still occurring with WinGet 1.8?

[anthonyvdotbe]

With winget v1.8.1791, following the Steps to reproduce no longer gives an error message, but now they both show with the same Id with winget list. However, if you explicitly do winget list --id Gyan.FFmpeg.Shared, it only lists one as expected. So there's still a bug here: