-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
winget should not error when installing the exact version of a package that is already installed #4262
Comments
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! Open similar issues:
Closed similar issues:
|
Additional context for why this behavior change is so important: Many computer systems, and as such the software installed on them, are managed with the intention of conforming to a certain, defined state and idempotency, i.e. a system or artifact such as a container image cannot simply change because it felt like it or because time has passed. Versions of software dependencies must be tested and updated in a controlled manner and are thus defined explicitly or pinned. As such, installing a specific version of a package such as a Java JDK would be the norm. We can currently install the latest version of a package initially, then not update it later. This behavior is often fine for systems that don't have to be 100% reproducible and don't have strict version requirements. This scenario is enabled by wingets But when we want to install a specific version of a package initially, and then stay on that version until someone explicitly chooses that it may be updated, we run into this error. We cannot use Thanks. |
@jantari I've had changes of opinion about this scenario over time. At this point with the new repair command, I think it does make sense for WinGet to essentially no-op when the specified version matches the installed version without "--force". I think of this internally as a "feature" since we're intentionally changing the current behavior, which was implemented as designed, but as it's being reported as a "bug" I'll keep the bug label. I'd like to see other folks add their 👍to help raise the priority. |
Thanks. If there was a different exit code, I could also handle the scenario in scaffolding scripts. But currently, when specifying a lower version than installed:
This returns the same exit code This is a success scenario / no-op (same version desired as is installed):
But fails with the same exact error. If I were to re-run this with It's a damned if I do, damned if I don't situation. Either way I'm going to break things some percent of the time. I would have to perform my own magic-fuzzy-version-number-matching ahead of running winget to determine whether I need to use I hope I'm able to get the usecase and issue across. |
Yeah, I also don't know if there is a reasonable Expected Return Code that might help more in this particular case. If that return code is unique to this scenario maybe we could add something to that affect.
|
I don't mean a return code from the installer, I mean the return code winget itself produces in this scenario. This is controllable by you and doesn't need special consideration in the manifests etc. -1978335189 is documented here: |
Brief description of your issue
When a package X of version Y is currently installed on the computer, attempting to install that exact package X in version Y again should not result in an error, because there is no operation that failed, it is simply a successful no-op.
The
--force
parameter exists to force a reinstall if the user desires.Steps to reproduce
Expected behavior
Winget should exit with return code 0 for success (nothing to do, the desired state is equal to the current state).
Actual behavior
Winget exits with exit code -1978335189 and the message "No applicable update found" when there was no intention to perform an update of any kind.
Environment
The text was updated successfully, but these errors were encountered: