marticliment
[BUG] Ignore non-matching updates
Please confirm these before moving forward
- [x] I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
- [x] I have tested that this issue has not been fixed in the latest (beta or stable) release.
- [x] I have checked the FAQ section for solutions.
- [x] This issue is about a bug (if it is not, please use the correct template).
UniGetUI Version
3.3.5
Windows version, edition, and architecture
Windows 10
Describe your issue
Lately I am seeing more and more cases where UnigetUI reports a "new version available" for some application (e.g. the Firefox Browser) and then tries to install but the install ends in a message "A newer package version is available in a configured source, but it does not apply to your system or requirements.". I assume with my "system or requirements" it means my system's Win x64 architecture. The annoying thing with these updates is, that they are reported as "updated successfully" and vanish from the list only to reappear AGAIN after the next scan. I.e. this is causing endless update loops! I expect UnigetUI to automatically ignore such updates (at least after the first failed attempt) and not show these again and again and again.
Steps to reproduce the issue
E.g. with Firefox update 143.0.3 ==> 143.0.4
UniGetUI Log
Package update operation for Package=Mozilla.Firefox with Manager=Winget
Installation options: <InstallOptions instance (only non-default values are shown)
InteractiveInstallation: True
Architecture: "x64"
OverridesNextLevelOpts: True>
Overriden options: <Scope=;RunAsAdministrator=;WG_SpecifyVersion=;PS_NoScope=False>
Version: 143.0.3 -> 143.0.4
Starting operation...
Executing process with StartInfo:
- FileName: "C:\Program Files\UniGetUI\winget-cli_x64\winget.exe"
- Arguments: "update --id "Mozilla.Firefox" --exact --source winget --accept-source-agreements --disable-interactivity --interactive --include-unknown --accept-package-agreements --force --architecture x64"
Start Time: "05.10.2025 12:41:44"
No applicable upgrade found.
A newer package version is available in a configured source, but it does not apply to your system or requirements.
End Time: "05.10.2025 12:41:48"
Process return value: "-1978335189" (0x8A15002B)
Mozilla Firefox (x64 en-US) was updated successfully
Package Managers Logs
Logged subprocess-based task on manager Winget. Task type is LoadPackageVersions
Subprocess executable: "C:\Program Files\UniGetUI\winget-cli_x64\winget.exe"
Command-line arguments: " show --id "Mozilla.Firefox" --exact --versions --accept-source-agreements "
Process start time: 05.10.2025 12:38:36
Process end time: 05.10.2025 12:38:37
-- Process STDOUT
...
Return code: SUCCESS (0)
Relevant information
No response
Screenshots and videos
Just FYI: Meanwhile I continued googling on this bug and found misc. hits explaining that issue this has to do with either different architectures (not applicable to my case - I'ld claim - since I always select "x64", i.e. definitely not ARM) or when the application was installed using different scopes (i.e. application was installed for a specific user when the installer's default scope is to install for all users (or vice versa)).
Running into the same issue with the Signal Messanger I thus deinstalled the application and re-installed it again using the default scope (i.e. letting the installer's default decide whether to install for me only or for all users). However, this did not fix this issue, after the next available update the Signal-update again keeps re-appearing in the update-list.
Thus, I conclude, there must be (also) some other reason for this to happen.
I am afraid this is more of an issue with WinGet, because it is detecting an update that really isn't
I feel like I made a change to have this hidden automatically? Isn't it in the settings somewhere?
