You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Schema extension to support multiple ARP entries. #1073
It would be really nice if there was a extension to the schema to allow a package manifest to list all of the ARP entries that an installer adds to support edge cases when winget tries to match packages to entries in the ARP table.
Per installer entry, there would be a array of "Programs" which captures the major metadata that the ARP table captures (property names are off the dome, they may conflict with something):
...installer info
Programs:
- ProgramName: Mozilla Firefox en-US
ProgramVersion: 89.0
ProgramPublisher: Mozilla
ProductCode: "{AAAAA-AAAAA-AAAAA-AAAAA-AAAAA}"
- ProgramName: Mozilla Maintenance Service
ProgramVersion: 3.4.1
ProgramPublisher: Mozilla
ProductCode: "{BBBBB-BBBBB-BBBBB-BBBBB-BBBBB}"
This would also require changes to the package manager client to allow it to match an ARP entry to a manifest even if the outer PackageName/Publisher/etc didn't match but there was a entry in the Programs array that did, of course. Maybe there's a better way to do this, but we're running into lots of issues where one language/architecture/etc adds a different entry to the ARP table than another language/architecture/etc meaning that winget has trouble matching them.
Edit: In addition to the client itself, there will have to be some (probably breaking) changes to the SQLite preindexed file that is used for the data from the community repo. I'm not jealous of whoever has to implement those...
Or we can just update it every time we make a new manifest. I just used Firefox as a example, the JetBrains apps, Python, and a lot of other apps have funny ways of naming things for the ARP table that are different than how you'd want them to appear in the package repository.
Anders (@sredna) we've been playing with various regex combinations and the wildcard leads to other trouble with packages that do side by side installs with minor variations depending on architecture, and user vs. machine. We're still thinking through the next best solutions.
Reacted by Easton Pillay, Dave Schulman and LudovicFoltete
Edit: Changed "ProgramsAndFeaturesEntries" to "AppsAndFeaturesEntries" to align with Windows 11 UI naming. "Name", "Publisher", and "Version" renamed to "AppName", "AppPublisher", "AppVersion".
The validation pipelines aren't updated yet. Building the new client is a prerequisite as we use the client itself in the validation pipelines. This should be testable via local manifest files, but they are not yet supported in the community repository. That work is in progress.
Activity
sredna commentedon Jun 4, 2021
You probably need wildcard support to find the Firefox ARP key:
Mozilla Firefox *as it seems to change the key name every time you update Firefox.jedieaston commentedon Jun 4, 2021
Or we can just update it every time we make a new manifest. I just used Firefox as a example, the JetBrains apps, Python, and a lot of other apps have funny ways of naming things for the ARP table that are different than how you'd want them to appear in the package repository.
denelon commentedon Jun 4, 2021
Anders (@sredna) we've been playing with various regex combinations and the wildcard leads to other trouble with packages that do side by side installs with minor variations depending on architecture, and user vs. machine. We're still thinking through the next best solutions.
denelon commentedon Jun 23, 2021
We need to make sure we include documentation on the logic used to perform the matching between the manifest and the entry in Add / Remove Programs.
denelon commentedon Jun 30, 2021
How about:
Edit: Changed "ProgramsAndFeaturesEntries" to "AppsAndFeaturesEntries" to align with Windows 11 UI naming. "Name", "Publisher", and "Version" renamed to "AppName", "AppPublisher", "AppVersion".
denelon commentedon Sep 17, 2021
https://github.com/microsoft/winget-cli/releases/tag/v1.0.12576
The validation pipelines aren't updated yet. Building the new client is a prerequisite as we use the client itself in the validation pipelines. This should be testable via local manifest files, but they are not yet supported in the community repository. That work is in progress.