Replies: 2 comments 2 replies
-
After install, we could check if the software's DisplayVersion key exists, and if not, winget can create a key like I don't know if it has been suggested before, but instead of relying on DisplayVersion, WinGet could always store manifest's PackageVersion to |
Beta Was this translation helpful? Give feedback.
-
|
Both of your points rely on being able to detect the ARP Entry which changed. In the case of Multi-Component packages, this isn’t always accurate or possible. If a package installs a VC++ Redist as a sub component, we wouldn’t want to set the WinGetVersion or the DisplayVersion, since the VC++ Redists are handled as separate packages. To avoid this, a lot of additional logic would need to be implemented. Additionally, adding a WinGetVersion key would essentially be using the same solution Chocolatey does, where they keep a list of every package and version they installed. Going to a solution like that instead of just using the existing AppsAndFeaturesEntries doesn’t seem to make a lot of sense to me, especially given that ARP matching already covers 99% of the discrepancies between Marketing Version and DisplayVersion. In fact, the only case that I believe isn’t covered is where a package has a null DisplayVersion |
Beta Was this translation helpful? Give feedback.
-
|
Possible edge case: A package does not write it's version to ARP, and then winget modifies the ARP to add it in some way. Then the package is uninstalled/upgraded/downgraded outside of winget, but it doesn't behave well and leaves the ARP intact. Now winget has wrong information about the package, which is probably worse than missing information. Admittedly this may not ever happen and I didn't even try to think too deeply about it. |
Beta Was this translation helpful? Give feedback.
-
|
I would argue this edge case already exists, as there are publishers who do not clean up their ARP entries on uninstall. I've even logged a feature request for it - #2171 |
Beta Was this translation helpful? Give feedback.
-
Background - CLI
There are many packages which do not report a package version, and which the App Developers have no intention of fixing themselves, or where the app is no longer being actively maintained. In the past there has been requests from users for WinGet to automatically set the ARP entries for these (and all apps). Although this has been considered lightly in the past, it has (from my understanding) been a sticking point, largely in part due to the automatic modification outside of what the publishers have defined.
Background - Usage
Packages which do not report a package version certainly have been a pain point for users in the past. While this has been mitigated in part due to the exclusion of such packages from
winget upgradeby default, it isn't a perfect solution and leaves WinGet unable to track the true version of these packages.Due to the use of the Add and Remove Programs table to gather information on which packages are installed, users are still able to "report" a package's version manually by modifying the appropriate registry key. While this is trivial to do for a power user, it can be difficult (and potentially scary) for a standard user to find the correct registry key to modify, especially given all the warnings about the risks of manually modifying the registry.
Consideration
Given that users can still modify their registry manually, I believe that having a way to "register" a version to those with unknown version is something which should be given more thought. Here are some of the items that I have been considering and why I think they may or may not be appropriate solutions
Adding a Manifest Key to write the version
This is similar to the initial suggestion which was made a while back to always overwrite the version in the registry, but it would be entirely dependent upon the maintainers of the package reporting the version to write. In my opinion, this solution has a few flaws. First, it still would be an automatic modification outside of what the publisher wishes. This could have unintended consequences on the behavior of apps that use their version in registry for automatic update checking and could be subject to incorrect manifest data. Additionally, this would rely on the detection of the changes to the ARP table at install. For multi-component packages, or even packages which install side-by side, this could lead to the wrong ARP entry being modified. This would need to be an opt-in only feature. This runs into the same pitfalls of the initial suggestion, and I would expect this to not be implemented for those reasons.
Having an argument to write the version
This solution may be slightly better than having a manifest key, as it wouldn't require a setting for opting in, but ultimately has the exact same problems. I won't go into further detail as it would simply be a different way to access the same functionality.
Doing nothing
This is the current approach. Meet the publishers where they are, communicate best practices, and rely on time to get the packages to a state of equilibrium. Although this isn't a bad approach, I think it leaves room for growth. As mentioned above, users can still manually modify the registry. Having read through many of the issues filed around unknown versions, it seems to me that many users are interpreting
Unknownas an error with WinGet, rather than how the publisher writes to the ARP entry. This is something which could be solved through Docs, and has been answered multiple times by community members on the issues which have been filed. However, having no solution to report the version could leave a negative impression on some users. While this isn't the most impactful portion of the user experience, I believe it has heightened importance to users as the perception of a package manager is to register and record versions of the applications it updates.Add a command
A command would provide users a manual way to update the registry without going into regedit, and would ensure registry entries are written "correctly". The command could easily be controlled through an admin setting, could provide a warning / confirmation prompt to users, and would solve many of the issues the other proposals have. While it could still have unintended consequences on the behavior of the application, the user would have had to consciously make the decision to run the command to modify the ARP entry, and agreed to the warning (if present). Multi-component packages wouldn't need to be worried about, as the ProductCode, or combination of the DisplayName/PackageName and Publisher could be used to ensure the correct entry is being modified. Finally, it could also enable automatic modification. When a user manually registers a version, an additional key can be added along the lines of
WinGetUserModifiedARP. If a user has manually registered a version to a package, and then the package is detected for an upgrade, the Package Version can be safely written to the DisplayVersion when installing the upgrade.Additional arguments could even be added to set the displayed publisher, help link, etc. If the product code isn't found, there could be a sub-command for registering a new ARP Entry, which could allow users to register a package when it doesn't write any values to ARP.
Further Discussion and Additional Questions
Beta Was this translation helpful? Give feedback.
All reactions