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.93k stars 1.42k forks source link

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

Open JohnLukeBentley opened 2 years ago

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

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.

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:

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

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:

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:

Trenly commented 1 year ago

[Policy] Command-Upgrade

o-l-a-v commented 10 months 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: