`winget upgrade` V `winget upgrade --all` produces different sets of packages

[JohnLukeBentley]

Brief description of your issue

winget upgrade V winget upgrade --all produces different sets of packages.

Steps to reproduce

Here I run winget upgrade then winget upgrade --all ....

PS C:\Users\john> winget upgrade
Name                 Id                        Version      Available    Source
-------------------------------------------------------------------------------
IrfanView            IrfanSkiljan.IrfanView    4.51         4.58         winget
Microsoft Edge       Microsoft.Edge            97.0.1072.55 97.0.1072.62 winget
PSpad editor         JanFiala.PSpad            4.6.0.2700   5.0.6.589    winget
VeraCrypt            IDRIX.VeraCrypt           1.22         1.25.4       winget
Yubico Authenticator Yubico.Authenticator      3.1.0        5.1.0        winget
Signal               OpenWhisperSystems.Signal 1.27.4       5.27.1       winget
Hue Sync             Philips.HueSync           1.6.1.12     1.7.0.19     winget
7 upgrades available.
PS C:\Users\john> winget upgrade --all
Found IrfanView [IrfanSkiljan.IrfanView] Version 4.58
Found PSpad editor [JanFiala.PSpad] Version 5.0.6.589
Found Signal [OpenWhisperSystems.Signal] Version 5.27.1
Found  [IrfanSkiljan.IrfanView] Version 4.58
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licences to, third-party packages.
Downloading https://download.betanews.com/download/967963863-1/iview458_x64_setup.exe
  ██████████████████████████████  3.56 MB / 3.56 MB
Successfully verified installer hash
Starting package install...
Successfully installed    
.... [Other install output omitted]

Expected behavior

The same list of packages.

Actual behavior

Observe that the following packages are listed under winget upgrade but not winget upgrade --all

• Microsoft Edge
• VeraCrypt
• Yubico Authenticator
• Hue Sync

Environment

Windows Package Manager v1.1.13405
Windows: Windows.Desktop v10.0.19043.1466
Package: Microsoft.DesktopAppInstaller v1.16.13405.0

Notes

This issue is separate to #752 (even if it turns out to have a common cause). I also experience #752.

[derkrasseleo]

I've also experienced this issue in the past, but I can't remember which packages caused it.

[OfficialEsco]

winget upgrade shows any higher version than the one you got installed.
winget upgrade --all probably does a background check before it outputs Found so it only installs the Packages that match your criteria.

• Microsoft Edge: If you've never done winget install Microsoft.Edge you will have the exe version. We don't have the exe installer.
• VeraCrypt: I can see that there is a exe install for this software, we don't have the exe version because its not Unattended.
• Yubico Authenticator: I did find a exe installer for 5.0.2, so you might have installed the nullsoft version of this software? Currently they only release msi installers.
• Hue Sync: appears to be like Upgrade doesn't work for several packages #752 where it unpacks a MSI installer, so the InstallerType is actually msi, however the exe installer does not accept msi parms.

[JohnLukeBentley]

Thanks @leochras.

Thanks @OfficialEsco. I'm naive to winget as a developer. That is, I'm not sure how it works, or is supposed to work internally.

You have accounted for the differences, sometimes speculatively, between the two commands by pointing to: different installer types; and the Upgrade doesn't work for several packages #752 error. But, #752 reason aside, I'm not sure if in accounting for these differences you mean to suggest: the differences are something a user of winget should expect; or the differences point to an immaturity in the winget implementation that we should hope to be fixed.

Whatever your intentions I suggest the later applies, for:

• In my example winget upgrade claimed there were "7 upgrades available". Yet winget upgrade --all did not find "7 upgrades available". If winget upgrade claims there are a specific number of available to upgrade then they should be upgradeable through winget.
• You point to "We don't have the exe installer." I take it you mean to suggest that winget doesn't have access to a package manifest that points to a location where the exe could be found (this would be true in this example, I manually downloaded the exes for those three programs: Microsoft Edge, VeraCrypt, Yubico Authenticator). In that case either winget upgrade :
  • Should not list them at all (recommended); or
  • Count them, and flag them in the user output, as not upgradeable through winget.

[OfficialEsco]

Its the immaturity of winget-cli.

These issue are in Preview, Work in Progress or in the backlog.

winget upgrade issue can soon upgrade from one InstallerType to another InstallerType which will fix the #752 issue.

The manifest schema have a AppsAndFeaturesEntries feature that we can use to workaround the different InstallerTypes, however winget-cli is behind.

The "We don't have the exe installer." is either because

• they don't release exe installers anymore
• the exe installer is zipped
• there is a dependency/driver issue
• the installer is unattended

Winget-cli version 1.2 will have support for dependencies that we have as a Package, which means we can add a bunch more installers when that is supported.

Most of the winget issues is winget-cli lacking behind what we can do in the manifest.

At the same time wingetbot and wingetcreate needs to support manifest schema 1.1.0, currently only YamlCreate supports manifest schema 1.1.0 because we main contributors use it, however we cannot add too much metadata since it can be broken by someone using wingetcreate.

[JohnLukeBentley]

Thanks @OfficialEsco.

"Its the immaturity of winget-cli .... Most of the winget issues is winget-cli lacking [lagging] behind what we can do in the manifest." noted.

And earlier you mentioned

winget upgrade --all probably does a background check before it outputs Found

That sounds right.

Whatever lagging issues you point to entail I suggest that:

• winget upgrade should be refactored to point to the same code base that winget upgrade --all uses in doing it's background checks. So that the same list of "upgradeable" packages be produced; and

• (In addition) winget upgrade use the same output style, as with winget upgrade --all , for the initial listing of found packages. That is, use the table format, like this

  PS C:\Users\john> winget upgrade --all
  Name                 Id                        Version      Available    Source
  -------------------------------------------------------------------------------
  IrfanView            IrfanSkiljan.IrfanView    4.51         4.58         winget
  PSpad editor         JanFiala.PSpad            4.6.0.2700   5.0.6.589    winget
  Signal               OpenWhisperSystems.Signal 1.27.4       5.27.1       winget
  
  Found  [IrfanSkiljan.IrfanView] Version 4.58
  This application is licensed to you by its owner.
  Microsoft is not responsible for, nor does it grant any licences to, third-party packages.
  Downloading https://download.betanews.com/download/967963863-1/iview458_x64_setup.exe
    ██████████████████████████████  3.56 MB / 3.56 MB
  Successfully verified installer hash
  Starting package install...
  Successfully installed    
  .... [Other install output omitted]
  

When using winget upgrade --all it is desirable to have listed "[Current] Version" and "Available [Version]".

This second suggestion could well be raised a separate issue. But I mention it here as it is tightly related. Indeed if this suggestion were taken up it would also take care of a recent issue I raised winget upgrade --all. Insert blank line after initial "Found" list. #1858.

A third suggestion: for consistency "Version" should probably be changed to "Current". That is, so the column headings in the table read as "Current" and "Available" with "Version" being implied in both cases.

Edit: Fixed link to issue 1858.

[FurtadoPires]

Another example in this case:

winget upgrade found Oracle.Virtualbox but typing winget upgrade Oracle.Virtualbox returns "No applicable update found"

winget upgrade --all also does not find Oracle.Virtualbox in this case

[OfficialEsco]

winget upgrade found Oracle.Virtualbox but typing winget upgrade Oracle.Virtualbox returns "No applicable update found"

This is the same issue as #752, I "fixed" this in the 6.1.32 manifest yesterday, so it will be resolved whenever the fix is implemented ¯\_(ツ)_/¯

[JohnLukeBentley]

Given pull request #1866, 'Print the upgrade table during upgrade --all' associated with issue #1858 'winget upgrade --all. Insert blank line after intial "Found" list.' .... the initial upgrade table for winget upgrade --all is now (as of when the relevant release is rolled out, or you access the source code) output.

The initial upgrade table printed by winget upgrade --all now reflects the output by winget upgrade.

So that makes the current issue purer. The current issue is now just a matter eliminating of any difference between the package sets in:

• The 'upgrade table' shown either initially by winget upgrade --all or entirely by winget upgrade; and
• For winget upgrade --all: the subsequent per-package upgrade output.