Feature: winget exclude <package>

[denelon]

Related to:

• Exclude packages from Windows Package Manager #2339

Open questions:

What should happen when a user tries to manually upgrade/install/list packages that have been excluded?

Impact for packages with dependencies on newer versions.

[OfficialEsco]

How is this use case different than #476 ?

Originally posted by @Trenly in #2339 (comment)

I don't see the difference other than a BLACKLIST from a Business/Enterprise view

Alternatively --include-excluded?

[Trenly]

After thinking more, I suppose a minute detail would be that "Blacklisted" packages wouldn't be shown in list or export?

[denelon]

That is part of the reason I was considering this feature in addition to the PIN behavior.

[henrikrxn]

My main use of exclude would be to avoid "false positive" upgrades. Currently 4 of the 7 upgrades I see are false positives.

There have been many since Winget started, but to mention a few

• .NET Core runtimes
• Microsoft Windows Desktop Runtime - 6.0.6 (x64) Microsoft.DotNet.DesktopRuntime.6 6.0.6.31318 6.0.7
• SQL Server Management Studio sub-packages
  • Microsoft Help Viewer 2.3 Microsoft.SQLServerManagementStudio 2.3.28307 15.0.18420.0
  • Microsoft SQL Server 2012 Native Client Microsoft.SQLServerManagementStudio 11.4.7462.6 15.0.18420.0
  • Azure Data Studio Microsoft.SQLServerManagementStudio 1.37.0 15.0.18420.0

I would like to be able to:

• exclude (name, id) pairs to avoid seeing them all the time I run winget upgrade
  • Maybe with adding version and/or available version to the exclusion entry
• Have a switch similar to `--include-unknown' to include them when I want to check, e.g. --include-excluded as suggested by @OfficialEsco above

[Trenly]

Sounds like most of that would be covered by Pinning; Have you read through this draft specification - https://github.com/microsoft/winget-cli/pull/1894/files

[henrikrxn]

No I have not. I often do not want to pin at the version.

What I want is to use exclusion to remove "false positive" upgrades.

I would like the possibility to be notified when newer versions show up.

One of the causes of false positives could be using incorrect version numbers when building the manifest.

I'm guessing that this `Microsoft Windows Desktop Runtime - 6.0.6 (x64) Microsoft.DotNet.DesktopRuntime.6 6.0.6.31318 6.0.7`` could be that because I got the same with for 6.0.5.XXXXX and 6.0.6

My guess is that the SQL Management Studio problems seem related to bundling several applications and giving the the same version number in the manifest, but I have not checked.

[Trenly]

The SSMS issue should already be resolved.

As for the .NET Runtimes, thats an issue with side-by-side installation detection (or multiple versions installed detection) which is being tracked and will be fixed.

I’m not against the idea of an exclusion list, but it seems counterintuitive to me to add a feature for the intent of hiding bugs. I think it would be a better use of development time to fix the root causes - ultimately removing the false positives.

Additionally, pinning should provide the same effect in terms of hiding the false positives. If you were to pin SSMS (once the feature is released), then it wouldn’t be considered for upgrade unless you specified --include-pinned, effectively removing the false positive while still being able to check if new versions are available.

I’m sure there are some uses for a blacklist, but I’m still not seeing how it provides additional value above and beyond pinning, which, based on your description of desired outcomes -

• Hides false positives / Hides specific packages
• Able to still be notified of new versions

these effects pinning would suffice to create

[Chiramisudo]

This is an important feature because there are several packages that must be updated separated and are not compatible with winget upgrade. For example, Microsoft Office, SSMS (SQL Server Management Studio), LINE (chat app), Vivaldi (browser), to name but a few. I'm not sure if there's a common thread between these types of apps that prevents them from working with this command, but as it stands, when winget tries to upgrade them it just wastes time because it always ends in failure and/or hangs up the other updates.

[Marcuse7]

This blocking feature would be very valuable for enterprises where certain packages must not be installed. Any way of blocking a package from installation would be helpful.
I have tried winget pin add --id package_id --blocking but afterwards winget install package_id still worked.

[Wallby]

I think I see the use for this. As currently all things installed from the Visual Studio Installer are listed for winget update. While the update command only opens the visual studio installer (at least it did, if it still does that). I'd rather blacklist them, or "graylist" them such that they do show up when running winget update, but are greyed out indicating they wont be updated if running winget update --all (only for being notified).

Edge also is listed every time, doesn't that by default update when a Windows update installs? Or when you close Edge?
https://support.microsoft.com/en-us/edge/microsoft-edge-update-settings