Matching logic needs to be updated.
denelon opened this issue · 13 comments
Brief description of your issue
Several packages aren't correctly being matched for several command flows.
Before we had the "displayName" key available in the manifest, we had to try and match the "packageName" in the manifest against the "displayName" in the registry.
Now we need to change the behavior so that when the "displayName" key is present in the manifest WinGet will stop trying to find a match by dropping the values in parenthesis at the end of the registry key mapped to the Windows Apps & Features "displayName".
Steps to reproduce
This is only one example of how this bug manifests:
This exact example was reported by @K8-and-a-half-1000
PS C:\> winget install -e --id Microsoft.VCRedist.2012.x86; winget install -e --id Microsoft.VCRedist.2012.x64
Found Microsoft Visual C++ 2012 Redistributable (x86) [Microsoft.VCRedist.2012.x86] Version 11.0.61030.0
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://download.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-B699-5E9B7962F9AE/VSU_4/vcredist_x86.exe
██████████████████████████████ 6.25 MB / 6.25 MB
Successfully verified installer hash
Starting package install...
Successfully installed
Found an existing package already installed. Trying to upgrade the installed package...
No applicable upgrade found.
In this example, WinGet installs the right package "Microsoft Visual C++ 2012 Redistributable (x86)", but during the subsequent install of "Microsoft Visual C++ 2012 Redistributable (x64)", the previous package is a false positive match leading to the upgrade flow for the "(x86)" which is already up to date.
Expected behavior
When a manifest contains the "displayName" key, the heuristics trying to match the "packageName" with the installed packages "displayName" should be ignored.
Actual behavior
False positives matching the wrong package are occurring.
Environment
Windows Package Manager (Preview) v1.5.441-previewI may have a similar issue. But my issue may contain another issue inside of it. Anyways. My issue is that I have Firefox installed. I then ran winget upgrade. It then said that there was an update to Firefox. So I did winget upgrade Mozilla.Firefox. It did it's thing. I then opened Firefox and saw that it had been updated. I then ran winget upgrade again. I then got
PS C:\Users\xx> winget upgrade
Name Id Version Available Source
--------------------------------------------------------------------
Mozilla Firefox (x64 en-US) Mozilla.Firefox 110.0 110.0.1 winget
1 upgrades available.
So I ran the upgrade command for Firefox again, and I then got
PS C:\Users\xx> winget upgrade Mozilla.Firefox
No installed package found matching input criteria.
I am not sure of the issue. If it matters, I had Firefox installed on my internal HDD and not my internal SSD. I then uninstalled it and then reinstalled it on my SSD. I forgot if I used Winget to remove and then reinstall it or not. Not sure if that matters.
Check to see if you have more than one entry in Windows Apps & Features. That's often a source of the complexity. If WinGet sees multiple results it doesn't know which one to act on.
Sometimes built in "upgraders" also don't modify the "displayVersion" key used in Windows Apps & Features. It would appear as an earlier version is installed, which is also a reason why WinGet would show an upgrade available.
You could see version 1.0 in Windows Apps & Features, but when you look at the "about" in the application, you would see the newer version.
I do have two entries for Mozilla.Firefox. However, even when I uninstalled it via Settings > Apps. There are still two entries in the Apps section. I then still have the same issue I had before with winget
If you removed both and the entries are still present, I'd suspect the installer/uninstaller isn't cleaning up the entries. WinGet will still have problems if there are erroneous entries. You may need to manually remove the entries.
When a manifest contains the "displayName" key, the heuristics trying to match the "packageName" with the installed packages "displayName" should be ignored.
Maybe we should completely ignore the heuristics if we have any ARP data on the manifest at all. If we have ARP data, we know exactly what we should find, so anything different wouldn't be the same app regardless of how similar it is
Maybe we should completely ignore the heuristics if we have any ARP data on the manifest at all.
For your consideration, it would help if the -e always ignored heuristics, so the result is deterministic.
A clear error is preferred instead of an unclear matching.
It also appears that this bug MIGHT be blocking install of other apps. MS edge needs to be updated. Winget sees the update but the update is NOT completed.
This is getting ridiculous.
I saw some of the file have AppsandFeaturesEntries:
Look at the following cases 0 file inside the setup which is InstallerData.
Rename 0 file to 0.xml.
Open it by using Excel.
It might some of the setup contains InstallerData.
Example Like ADK, ADKWinPEAddon, SDK, WDK, Dotnet, Vcredist.
If that file is exist, the AppsandFeaturesEntries is permanently used. If that file does not exist as 0 file, need to use winget list to see if it is same as Control Panel. If that winget display like this >118.0.5993.11. If your computer application display version registry is set by 120.0.6099.15. which is written by the setup. The older manifest might be possible case to be contains AppsandFeaturesEntries. If winget list does not match Control Panel, use AppandFeaturesEntries instead. If not the package version will be the same as all the time.
Can we please get an update that this is actually being worked on? The lack of proper matching makes Winget almost unusable. There are many features that I'd like to see that are still missing, but to me, version management is essential to a package manager, even more so than a good searching algorithm.
Currently, Winget seems to completely uninstall "Visual C++ 2005 redistributable x64 8.0.61000" and then reinstall "Visual C++ 2005 redistributable x86 8.0.61001" which is already up-to-date. I think the x64 one is in fact also the latest version, but Winget is confused because the x86 version has a higher version number.