Better Respect Package installation sources

[kilasuit]

Description of the new feature / enhancement

Currently winget list seems to list all installed applications, and in many cases this is great. However it is not currently respecting that other tooling, like chocolatey, SCCM, intune or other package management solutions, may be in use for management of applications in estates already (like it is in mine) or that the application may have been manually installed as part of a short functionality test & should not become a winget manageable application which may be internal software or may be software installed direct from the web to have a quick nosy at it & see if it is worth keeping longer term.

It therefore would be handy to be able to specify for winget to only return applications that have been installed by it, so that any upgrade cycles that orgs and users have in place aren't fighting with winget & importantly if an org decides they are limiting the roll out of versions of software like Visual Studio or Office or other inner sourced version that need security team sign off & that process to allow use of newer versions isn't getting bypassed by how winget is currently blindly assuming that any installed application that matches a package listed in the winget packages repo is fair game for being auto managed by winget going forward.

Adding this feature will help IT Admins, Developers & Security teams in being able plan out whether they are going to migrate application management entirely to winget or keep what they currently have & allow winget for new packages & keep existing ones in their tooling of choice. Especially if this is a mixed environment with other Microsoft tooling like Intune, or SCCM, PowerShell DSC, Azure Machine Config or other 3rd party tools.

This was found as part of me trying to look into what was happening with how PowerShell can be released & available on winget and unable updated due to a package ID mismatch thanks to a previous update via Microsoft Update as discovered in this PowerShell issue & noticing that all my chocolatey installed applications show, whether or not there is an update available on winget or not.

1488 - I think is a potential starter for this with the priority scale however there will be times when you want to set a per package ID source priority , example being you may be testing out an internal vendor build of an application to verify a bug fix prior to them releasing to either winget or their main package source feed.

Proposed technical implementation details

• [ ] implement a InstalledByWinget attribute for packages
• [ ] on find a package should be returned with a warning note of not installable via winget if the ID matches the install was via another source that winget cannot pass an install request off to
• [ ] on install a package should check if it is managed elsewhere and throw an error to the user if install is attempted unless admin settings allow the user to override the previous installation source (I.e to allow winget to manage it)
• [ ] on listing installed packages, it should check this store, prior to mapping the source as winget & if not via winget, should return unknown, unless winget adds ability for other package management tools to show as sources
• [ ] on upgrade, a package that was installed via other means but is available via winget should prompt for user input on whether this should now be managed by winget, unless it is already deemed managed via another package manager & ideally delist it as a managed package from the other package manager as not to have conflicts between them
• [ ] enable option to delist from winget a package that was once installed by it, as it has a self updating mechanism that is already in use so no longer needs maintaining by winget (should stay in the store as having initially been installed by winget)

[stephengillie]

This duplicates --pin functionality. Basically, you're requesting a way to pin packages in the package manager that weren't installed by it.

[denelon]

There is a lot to unpack in this feature request. I appreciate the time it took to articulate the desired behaviors and the scenario where they apply. I'll put some initial thoughts below:

Enterprise customers can stand up their own "private" REST source for WinGet packages and disable the default sources to ensure WinGet is only updating/installing packages coming from the configured source(s).

WinGet does have a local tracking database for packages installed by WinGet, but it's currently only used to help with correlation to the source a WinGet package came from.

The WinGet List command is displaying all installed packages and attempts to correlate any installed package against what is available in any configured source.

WinGet does not prevent users from downloading and installing software using other means. Some packages also have their own mechanisms for auto-updating software when new versions become available. WinGet does not block any of those mechanisms. There would be some interesting edge cases where WinGet may not have been used for an initial install or an intermediary update so reasoning about "installed by WinGet" might be a bit challenging from a UX perspective.

It is possible to "Pin" any packages that WinGet should not attempt to upgrade, but this also requires those packages to be available in one of the configured sources.

[florelis]

(We may get confused if we call Chocolatey, SCCM, Intune, etc. "installation sources" because winget has its own concept of a "source". I'd call them "package managers".)

We may be able to distinguish apps installed by specific package managers by data in the ARP. If we can do that, then we probably should leave them alone because we can tell we don't know how to handle them. I don't know if there is any such data but we could look into it.

For other package managers that, like winget, basically run an existing installer, I don't know if we can tell the difference between a manual installation and an installation through that other package manager. In that case the pinning may work.

Maybe we could have an option to not try and correlate ARP data with available packages, and instead just use the tracking catalog. That would limit a lot what we can do, but seems like it may be desired in some cases.

[whindsaks]

We may be able to distinguish apps installed by specific package managers by data in the ARP

There is no standard for package managers to mark themselves as the handler of installed applications in ARP nor other places.

Microsoft could of course define such a value if they wanted to.