Uninstall requires source agreements

[Trenly]

Brief description of your issue

After installing a package from the winget source or a local manifest, I am required to accept the msstore agreemenst before I am able to use winget to uninstall the package. Specifying a source on uninstall suppresses the message

Steps to reproduce

1) Boot into a fresh vm or sandbox environment and ensure winget is installed 2) Run winget install Google.Chrome --source winget and ensure the application installs successfully 3) Run winget uninstall Google.Chrome

Expected behavior

I expect the package to be uninstalled without additional prompts. If a package was installed from the community repository or a local manifest, there should be no need to agree to the msstore terms in order to uninstall it.

Actual behavior

I am required to agree to the msstore terms. Using winget uninstall Google.Chrome --source winget does not prompt for the terms of service

Environment

PS C:\Users\WDAGUtilityAccount> winget --info
Windows Package Manager v1.1.12653
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.1348
Package: Microsoft.DesktopAppInstaller v1.16.12653.0

[denelon]

@Trenly this is an interesting one. The "uninstall" command is looking at all configured sources to see if there is a manifest matching an installed package. That's why the prompt is triggering. The "msstore" source also gets queried for the meta-data since it's configured. I'll have to see what kinds of options we might have in a case like this.

One options might be to inform the user about this being the first time the "msstore" (or any source with an agreement) had been queried.

I believe one should be able to pass --source winget during uninstall to prevent the "msstore" source from being queried looking for a matching package.

[Trenly]

Yes, you can pass —source winget, and that will suppress the agreements, but I don’t understand why it may be necessary to query the source.

Especially since a manifest which was installed locally for a package which does not exist in the msstore or winget source will uninstall perfectly fine

Maybe thats where the additional documentation comes in

[denelon]

Commands don't require an explicit package Id and source. Any time we try to correlate something installed on the system with a manifest in a source, we need to query the source. If one isn't specified, we query all configured sources.

Yes, that's where the documentation comes in. It's not obvious that list, uninstall, and upgrade are driven by looking at installed packages via Apps & Features, and then we need to query sources to see if we have corresponding manifests we can use to display information, or take action.

[keentext]

Yeah, winget is just the worst, this kind of trash is extremely representative of microsoft's engineering practices: "we don't care about the user and we don't care about the product, I just want my christmas bonus"

[Trenly]

Yeah, winget is just the worst, this kind of trash is extremely representative of microsoft's engineering practices: "we don't care about the user and we don't care about the product, I just want my christmas bonus"

I understand you may not agree with the process that Microsoft uses, but it is extremely prejudicial to make such wide reaching blanket statements. I know from experience that there are many engineers at Microsoft who do care about the user and many others who do care about the products. Even this issue is an example that they do care. The fact that it has been marked as feature request rather than being closed shows that they are listening and that they do want the Windows Package Manager to be the best that it can be for the user. Certainly the first step starts with documentation of why it is behaving the way it does, but they are also taking that next step of re-evaluating and looking to see how can the product be made better for the user.

[vedantmgoyal9]

1745

[keentext]

I understand you may not agree with the process that Microsoft uses, but it is extremely prejudicial to make such wide reaching blanket statements.

these statements come from years of experience.

I know from experience that there are many engineers at Microsoft who do care about the user and many others who do care about the products.

yet, time and time again the result we get is broken stuff, bloated products, legacy stuff that should die continue to exist, and things that should be reengineered with what we know now will not be reengineered because it's too expensive, we can keep pushing windows with just a new theme .

[denelon]

I'm looking to update the documentation at Microsoft Learn for this particular scenario, so users understand what is happening. As we're looking to add arguments for the uninstall flow, it doesn't necessarily make sense to exclude a source from being searched in this case, but at least we can update the documentation to explain why this is happening.