search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
22.55k stars 1.4k forks source link

Documentation when installer types change #4391

Open denelon opened 2 months ago

denelon commented 2 months ago

When installer types change between versions of packages, WinGet displays:

A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.

This causes users to be frustrated and or confused. Documentation should be added to Microsoft Learn for this case so users can be informed about the options, and the reasons for WinGet's behavior. In addition, an aka.ms URL should be added to the error message output so users can get more information and understand their options.

The choice was made to handle installer type changes by informing the user. If the manifest indicated "uninstall previous" was the default behavior, then the previous version would be removed and the newer version would be installed. This is a case where a user might want "both" versions to remain, or the user might "need" both versions to remain (at least until any package specific data was migrated).

WinGet needs to have some "default" behavior in cases where the consequences of installing a newer version of an arbitrary package might not be well understood. Arguments like "--force" and "--uninstall-previous" are present so a user can control WinGet's behavior.

I completely get the frustration here, and I encounter it myself regularly when installing and updating all kinds of packages. WinGet doesn't special-case behaviors for specific packages or publishers (not even Microsoft as a publisher). Our goal is to make the best "default" choice, so users aren't sad/mad/frustrated. Sometimes there isn't a single best solution, and in those cases, we defer to the user.

Dealing with decades of entropy in terms of legacy installers, and a world of change isn't easy. I don't have all the answers. That's one of the primary benefits of being open source and having these kinds of discussions. If we can come up with better solutions together, everyone benefits.

I do appreciate the honest feedback, even when it's negative. Thank you for taking the time to share it.

Originally posted by @denelon in https://github.com/microsoft/winget-cli/discussions/2155#discussioncomment-9168359

huyz commented 2 months ago

Would it also be a good idea to detect and inform the user what the other "installer technology" is, even if only possible part of the time?

denelon commented 2 months ago

I'm open to that. I don't know users necessarily understand, but if we're linking to documentation with guidance they could certainly learn. WinGet does know the installer type for the currently installed version in almost every case, and it does know the new type based on the manifest for the newer version, otherwise the error message wouldn't be possible.

huyz commented 2 months ago

I think it would go a long way. I don't have a problem with having to uninstall. I just have a problem with not knowing what the next step is. If I knew how something was installed, I'd have a better idea of what to do next

SiJiL82 commented 1 week ago

I would say users would be more likely to understand "technology has changed from X to Y" significantly more than the vague "It's changed, but we're not going to tell you what from or to!"