winget should not error when installing the exact version of a package that is already installed

[jantari]

winget should not error when installing the exact version of a package that is already installed

[jantari]

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:

https://github.com/microsoft/winget-cli/blob/master/doc/windows/package-manager/winget/returnCodes.md#general-errors

[github-actions]

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:

• Winget says package is already installed, when it isn't (#3910), similarity score: 0.87

Closed similar issues:

• winget should not install an already installed package (#929), similarity score: 0.92
• Winget upgrade does not detect the correct version of an installed package (#3883), similarity score: 0.89
• Winget says unknown version for package it just installed (#1356), similarity score: 0.86
• Winget installing outdated packages (#2538), similarity score: 0.85

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[jantari]

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 --no-upgrade switch. This switch is important and works.

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 --no-upgrade because when an explicit version for a package is desired, it is not clear whether that constitutes an upgrade or not before winget install runs (at the time one chooses the parameters to pass). If I explicitly tell winget to install GIMP version 2.10.34, that may very well be an update on, say, 14 out of 60 targeted systems. So setting --no-upgrade is wrong and will not accomplish the goal of ensuring all 60 systems are on that specific version of GIMP. We also cannot use --force, because this causes a reinstall rather than a no-op when the same exact version is already installed. Reinstalling software in-place is often harmless, but causes an outage because the software is briefly unavailable, introduces risk because re-installation of software can always fail due to transient issues such as a reboot happening to be pending at the time or files being in use etc. and it also just wastes time because a no-op could be done in less than a second but uninstalling and reinstalling certain software can take minutes. Forcing an in-place reinstall is certainly something that we wouldn't do by default, just to work around this issue, if it could be solved any other way.

Thanks.

[denelon]

@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.

[jantari]

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:

winget install --id 'GIMP.GIMP' --exact --version '2.10.30' --silent --source winget

This returns the same exit code -1978335189, even though the users' intention was to downgrade the software.
I would have to re-run winget with --force to get the desired result, but I can't know that from the exit code.

This is a success scenario / no-op (same version desired as is installed):

winget install --id 'GIMP.GIMP' --exact --version '2.10.34' --silent --source winget

But fails with the same exact error. If I were to re-run this with --force, I'm in trouble. But I can't know that from wingets' behavior or exit code.

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 --force (at which point, If I determine the versions are identical, I just wouldn't run winget install anymore) - but that's something I'd rather not re-implement when winget already exists and handles the highly complex task of version matching.

I hope I'm able to get the usecase and issue across.

[denelon]

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.

"ExpectedReturnCodes": {
  "type": [ "array", "null" ],
  "items": {
    "type": "object",
    "title": "ExpectedReturnCode",
    "properties": {
      "InstallerReturnCode": {
        "$ref": "#/definitions/InstallerReturnCode"
      },
      "ReturnResponse": {
        "type": "string",
        "enum": [
          "packageInUse",
          "packageInUseByApplication",
          "installInProgress",
          "fileInUse",
          "missingDependency",
          "diskFull",
          "insufficientMemory",
          "invalidParameter",
          "noNetwork",
          "contactSupport",
          "rebootRequiredToFinish",
          "rebootRequiredForInstall",
          "rebootInitiated",
          "cancelledByUser",
          "alreadyInstalled",
          "downgrade",
          "blockedByPolicy",
          "systemNotSupported",
          "custom"
        ]
      },
      "ReturnResponseUrl": {
        "$ref": "#/definitions/Url",
        "description": "The return response url to provide additional guidance for expected return codes"
      }
    }
  },