search

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.54k stars 1.39k forks source link

Unable to upgrade k6 #4573

Open robross0606 opened 1 week ago

robross0606 commented 1 week ago

Brief description of your issue

winget lists an available upgrade for k6 but then doesn't let me actually install it. Instead, it just keeps complaining that the upgrade is available.

Steps to reproduce

winget upgrade lists the following:

Name Id    Version Available Source
-----------------------------------
k6   k6.k6 0.50.0  0.51.0    winget
1 upgrades available.

Then attempting winget upgrade k6.k6 gives this:

No applicable upgrade found.
A newer package version is available in a configured source, but it does not apply to your system or requirements.

Expected behavior

If an upgrade is listed as available, it should be installable.

Actual behavior

The upgrade is listed as available but then refuses to install.

Environment

Windows Package Manager v1.7.11261
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.4529
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.11261.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
github-actions[bot] commented 1 week ago

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:

Closed similar issues:

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

robross0606 commented 1 week ago

Big question: If the available package does not "apply to [my] system or requirements" then why is winget upgrade listing it as an available upgrade and trying to install it? Even doing winget upgrade --all throws the same error. Here are verbose logs from an installation attempt: WinGet-2024-06-21-09-50-05.344.log

robross0606 commented 1 week ago 
2024-06-21 09:50:07.076 [CLI ] Installer [X64,wix,User,en-US] not applicable: Installer scope does not match currently installed scope: User != Machine
2024-06-21 09:50:07.085 [CLI ] Terminating context: 0x8a15002b at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:bc

Looks like maybe k6 published the installer only in the "user" scope and I have this installed in "machine" scope? If that's true, then why isn't winget upgrade filtering this out properly? If the scopes don't match, it shouldn't be returned as a viable update because then winget upgrade --all fails too.