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

JohnLukeBentley commented 2 years ago

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 commented 2 years ago

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

OfficialEsco commented 2 years ago

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 #752 where it unpacks a MSI installer, so the InstallerType is actually msi, however the exe installer does not accept msi parms.

JohnLukeBentley commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Another example in this case: winget

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 winget_upg

OfficialEsco commented 2 years ago

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

This is the same issue as https://github.com/microsoft/winget-cli/issues/752, I "fixed" this in the 6.1.32 manifest yesterday, so it will be resolved whenever the fix is implemented ¯\_(ツ)_/¯

JohnLukeBentley commented 2 years ago

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.

Trenly commented 1 year ago

[Policy] Command-Upgrade

o-l-a-v commented 1 year ago

I don't know if this is related, but I see a difference in behavior with winget v1.6.2771 when upgrading Microsoft.PowerShell.Preview from v7.4.0.6 (preview 6) to v7.4.0.101 (RC1).

winget upgrade --all will say that it installs v7.4.0.101 as a dependency.

C:\Windows\System32>winget upgrade --silent --all
Name                     Id                           Version Available Source
------------------------------------------------------------------------------
PowerShell 7-preview-x64 Microsoft.PowerShell.Preview 7.4.0.6 7.4.0.101 winget
3 upgrades available.

The following packages have an upgrade available, but require explicit targeting for upgrade:
Name                         Id              Version     Available            Source
------------------------------------------------------------------------------------
Microsoft Teams              Microsoft.Teams 1.6.00.6754 23257.2618.2432.4374 winget
Teams Machine-Wide Installer Microsoft.Teams 1.5.0.8070  23257.2618.2432.4374 winget
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.
2 package(s) have pins that prevent upgrade. Use the 'winget pin' command to view and edit pins. Using the --include-pinned argument may show more results.

Installing dependencies:
(1/1) Found PowerShell Preview [Microsoft.PowerShell.Preview] Version 7.4.0.101
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.4.0-rc.1/PowerShell-7.4.0-rc.1-win-x64.msi
  ██▌                             9.00 MB /  103 MB
Cancelled

Cancelled
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.
2 package(s) are pinned and need to be explicitly upgraded.

C:\Windows\System32>

While winget install --silent --id Microsoft.PowerShell.Preview seems to behave as expected, treating Microsoft.PowerShell.Preview as the package to be upgraded.

C:\Windows\System32>winget upgrade --silent --id Microsoft.PowerShell.Preview
Found PowerShell Preview [Microsoft.PowerShell.Preview] Version 7.4.0.101
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.4.0-rc.1/PowerShell-7.4.0-rc.1-win-x64.msi
  ██████████████████████████████   103 MB /  103 MB
Successfully verified installer hash
Starting package install...
Successfully installed

C:\Windows\System32>

I see nothing obvious in winget-pkgs for Microsoft.PowerShell.Preview that would warrant this:

Reproduce:

Remove all PowerShell 7 preview versions. I used Geek Uninstaller.
Install 7.4 preview 6: winget install --silent --id Microsoft.PowerShell.Preview --version 7.4.0.6
Upgrade all, notice winget says "installing dependency": winget upgrade --silent --all
- Cancel it to check behavior when upgrading a specific package
Upgrade specific package, behaves as expected: winget upgrade --silent --id Microsoft.PowerShell.Preview

microsoft / winget-cli