Mark broken manifests with a flag instead of removing them from the repo

[chausner]

I have seen automated MRs that remove manifests when the URLs become unreachable. My suggestion is to not fully remove broken manifests from git but instead mark them with a new flag that makes the client not show these manifests but the manifests stay in git.

Let me explain why fully removing manifests from the repository might not always be desired:

One reason why URLs become unreachable is because there is a new version of the software with a new download link and the old link has gotten removed. Another reason is that the download URL changed. When those manifests get removed, it may not be apparent to other users that we already had manifests for the software, so when they find out that the software is not in WinGet, they likely start from scratch by writing a new manifest. To find out that there had been manifests before, they would have to search for old MRs or look at the git history which certainly not everybody does. Even then, it is cumbersome to restore those old manifests and update them.

It happened to me in the past that I started writing manifests for apps, only to find out that we already had well-written ones in the repository but they got removed because the link changed. I could have saved a lot of time by just taking the old ones and updating them instead.

By keeping broken manifests in git and marking them with a flag, it would be easier for users to discover those cases and fix them.

[chausner]

We might even want winget to include broken manifests in the search results. This way, users could still access metadata via winget show for software that is no longer available. If they attempt to install it, winget could show an error message explaining that the version is no longer available, and point users to the winget repository with a suggestion to contribute an updated manifest.

[denelon]

We had discussed an option to mark a package as "obsolete". The challenge is when they show up in search, a user would expect to be able to install it. We have a feature to @mention authors in the Issue that is generated with the warning that the package was unable to be downloaded before it is removed.

[jedieaston]

I've been thinking about this in the context of applications with open CVEs, where the CVE was patched in a newer version. If you still need the older version for compatibility, winget should let you install it with a warning that there is a active security vulnerability (not uncommon for bizarre LOB apps to need a specific build of Java or something that is vulnerable, I'd think we wouldn't want it installable without the end user knowing the risks but also don't want to just remove it entirely).

[chausner]

The challenge is when they show up in search, a user would expect to be able to install it.

True, I can see it would be confusing if they show up in the search results by default. Then let's just exclude them.

We have a feature to @mention authors in the Issue that is generated with the warning that the package was unable to be downloaded before it is removed.

That certainly helps for those packages where there's a maintainer who regularly updates manifests. But there will probably always be packages that are added initially by one person who has no interest in keeping it up-to-date all the time. So I still think the risk is too high that manifests are "lost" if nobody fixes them within the grace period.

I do think that there are cases when we want to remove broken manifests completely from the repository (e.g. software that is not available anymore). But this process should be manual or at least not happen so quickly after a URL changes. E.g. CI could wait for 6 months or so before completely removing packages that have not been fixed by maintainers or the community during that time. In the mean-time, the flag in the manifest would ensure that this package does not show up in the search.

[denelon]

It might make sense to add a feature to be able to search for these "obsolete" packages as well. There might be someone looking to port/fork/fix OSS packages that are obsolete.

[Trenly]

Related to:

• Package Tombstones #1900