-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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 upgrade
V winget upgrade --all
produces different sets of packages
#1854
Comments
I've also experienced this issue in the past, but I can't remember which packages caused it. |
|
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:
|
Its the immaturity of winget-cli. These issue are in Preview, Work in Progress or in the backlog.
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. |
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
That sounds right. Whatever lagging issues you point to entail I suggest that:
When using 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 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. |
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 ¯\_(ツ)_/¯ |
Given pull request #1866, 'Print the upgrade table during The initial upgrade table printed by So that makes the current issue purer. The current issue is now just a matter eliminating of any difference between the package sets in:
|
[Policy] Command-Upgrade |
I don't know if this is related, but I see a difference in behavior with
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 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
Reproduce:
|
Brief description of your issue
winget upgrade
Vwinget upgrade --all
produces different sets of packages.Steps to reproduce
Here I run
winget upgrade
thenwinget upgrade --all
....Expected behavior
The same list of packages.
Actual behavior
Observe that the following packages are listed under
winget upgrade
but notwinget upgrade --all
Environment
Notes
This issue is separate to #752 (even if it turns out to have a common cause). I also experience #752.
The text was updated successfully, but these errors were encountered: