Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
Some "portable" packages have their own internal "update" mechanism. If they get updated, and they were installed by WinGet, the registry metadata doesn't get updated.
This could lead to undesired behavior.
WinGet thinks the package is out of date and needs to be updated.
-
This could be turned into a no-op. If the latest version WinGet knows about matches the installed version, WinGet could update the metadata during the "upgrade" flow.
-
This could lead to a bad outcome if a newer version is installed than what WinGet is aware of and could lead to an upgrade loop in WinGet. This may justify a new "error condition" because WinGet doesn't know how to reason about the installed version. It could also have the "unintended" behavior of installing an older version of the package and clobber the newer one that was installed on the device.
Ideally, the latest version would be available in the WinGet repository, or the portable package could leverage WinGet to handle the upgrade flow to keep the registry metadata in sync. Otherwise, it would be good for the package to distribute an installer rather than a "bare portable executable".
Tools like the Windows App CLI can help build an MSIX packaged application including the binary. This is the ideal case in terms of package management, as Windows understands how to handle the situation, and WinGet isn't trying to keep the registry metadata in sync.
Optionally there are a large number of other supported installer technologies that can be used to build installers.
Proposed technical implementation details
No response
Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
Some "portable" packages have their own internal "update" mechanism. If they get updated, and they were installed by WinGet, the registry metadata doesn't get updated.
This could lead to undesired behavior.
WinGet thinks the package is out of date and needs to be updated.
This could be turned into a no-op. If the latest version WinGet knows about matches the installed version, WinGet could update the metadata during the "upgrade" flow.
This could lead to a bad outcome if a newer version is installed than what WinGet is aware of and could lead to an upgrade loop in WinGet. This may justify a new "error condition" because WinGet doesn't know how to reason about the installed version. It could also have the "unintended" behavior of installing an older version of the package and clobber the newer one that was installed on the device.
Ideally, the latest version would be available in the WinGet repository, or the portable package could leverage WinGet to handle the upgrade flow to keep the registry metadata in sync. Otherwise, it would be good for the package to distribute an installer rather than a "bare portable executable".
Tools like the Windows App CLI can help build an MSIX packaged application including the binary. This is the ideal case in terms of package management, as Windows understands how to handle the situation, and WinGet isn't trying to keep the registry metadata in sync.
Optionally there are a large number of other supported installer technologies that can be used to build installers.
Proposed technical implementation details
No response