Can we have package manifests for manual-only updates? (i.e. manual update hints)

[R-Adrian]

Description of the new feature / enhancement

Some software packages have licenses that specify that the download and / or installation are only free when users visit and manually download the package from their respective publisher and do not allow for automated downloads directly from their servers and/or silent installs.

e.g.
Nmap - https://nmap.org/oem/
Npcap - https://npcap.com/oem/
FileZilla - https://trac.filezilla-project.org/ticket/12768

there is currently in the works a "package deny" list... microsoft/winget-pkgs#97604
https://github.com/microsoft/winget-pkgs/blob/master/.github/policies/flaggedPackages.yml

but i think it would still be useful to have some sort of prompt and let the user know that there is a known newer version available and they should update it manually (or using that app's built-in updater, if it has such a function)

Proposed technical implementation details

in the WinGet package manifests have the possibility to define update packages like normal but instead of installer download url only specify a message to be shown in the terminal console, something along the lines of:

"We have detected that you have version xx.yy.aaa of package $XYZZY and there is a newer version available: yy.zz.bbb, but publisher license terms do not allow us to install or update it with WinGet. Please visit the publisher's website to download the update manually or add a blocking exclusion pin in the WinGet configuration to stop being notified about newer versions of this app."

[mdanish-kh]

but i think it would still be useful to have some sort of prompt and let the user know that there is a known newer version available and they should update it manually (or using that app's built-in updater, if it has such a function)

To provide this experience, the manifest needs to exist in winget-pkgs to correlate the installed package and determine an available update. If the URL does not allow automated downloads, it probably means the manifest would not pass the validation pipeline for adding it in winget-pkgs in the first place. The validation pipeline includes URL checks, defender checks, static analysis with the installer (and more) and running the installer in a hardened environment (detonation phase). This may mean we need to bypass or work around a lot of the security work done (which may not be a viable option?) or have some sort of "metadata-only" manifest?

[mdanish-kh]

[Policy] Command-Upgrade
[Policy] Area-Manifest
[Policy] Area-Output

[R-Adrian]

or have some sort of "metadata-only" manifest?

some sort of metadata-only manifest (without any linked installer) that causes WinGet to show an "update is available" hint in the console would be ideal, even if that hint is only in that versions summary table that is shown by the winget upgrade command.

Maybe treat such metadata-only packages as pinned (simple pinned, not blocking-pinned, unless they are explicitly block-pinned), and skip handling them when doing winget upgrade --all ?

Also, if possible, show in the terminal console some sort of verbose message when trying to upgrade that package explicitly with WinGet, detailing why such an upgrade with WinGet is not available/allowed - show some sort of descriptive text as in the example in the last paragraph of the Proposed technical implementation details from above

i think that some of the fields: Description, ReleaseNotes or InstallationNotes from the package manifest schema might be just right for including in the manifest such a verbose message to be shown for these types of metadata-only packages.

https://github.com/microsoft/winget-pkgs/blob/master/doc/manifest/schema/1.10.0/defaultLocale.md