Trenly
commented
2 years ago Here is a list of some use cases for Tombstones, as well as their associated issues/pr's
| Issue # | Use Case |
|---|---|
| microsoft/winget-pkgs#42432 | This package has a Dynamic CDN which means that the Sha256 of the installer is different depending on who is downloading it and when. Tombstoning this package with no version available would allow for anyone opening a PR for this package to be informed as to why the package will not be added, and to save resource time by not running the full set of pipeline scans on the manifest. |
| microsoft/winget-pkgs#41777 | This package has versions existing in the repository. However, newer versions of the package are unable to pass the AntiVirus scans. Tombstoning this package for specific versions would allow anyone submitting a version that is known to fail the AVScan to be informed, and to save resource time. This would still allow for new versions, which are not tombstoned, to be submitted and scanned, at which point a tombstone can be added for the new versions if necessary. |
| microsoft/winget-pkgs#16896 | Several different versions of this package have been submitted to the community repository, and all fail due to being blocked by dependencies. This may be due to a number of factors such as users not searching for closed PR's, thinking newer versions have no dependency requirement, or some other line of reasoning. Having the ability to tombstone packages would allow for the ability to avoid duplicate PR's and would create a better experience for the user by keeping them informed. Once dependency support is added, the tombstone could be removed |
| microsoft/winget-pkgs#45359 | When packages are no longer available, their manifests are removed. However, it is possible that a lapsed domain or other error may be transient. Having a tombstone would allow for the package metadata to be retained while removing the package from search results. This would allow for a package version to be restored more easily if a transient error is resolved. |
| microsoft/winget-pkgs#45299 | Some packages use vanity url's for their latest version. This means that the version history and associated metadata (such as release notes) are not retained when the package is updated. Implementing tombstones would allow the previous metadata to be retained while keeping the previous version in the repository. This would also allow for more manifests to have a vanity URL by allowing community members to update older versions with static version links and removing the tombstone after the manifest has been automatically updated. |
| microsoft/winget-pkgs#47643 | Some packages have different behavior depending on the region or locale the users system is set to. Being able to tombstone packages for specific regions while allowing them to remain active in other reasons would improve catalog health |
SpecterShell
upintheairsheep
Description of the new feature / enhancement
Sometimes a package is temporarily not available, or the publisher has chosen not to be included in the Windows Package Manager Community App Repository.
A new Tombstone.YAML file would be used to support this behavior.
If the file is in the package directory, it could be used to hold identifiers to help prevent future submission rather than what would likely happen if there was no manifest for the package. It may contain SHA256 values for known versions to help inform users when they try to submit a manifest that the package has been tombstoned and cannot be submitted.
If the file is in a version directory, that version would no longer be available for search, install, or upgrade, but it would still allow users who have the package (as a dependency) so they could still install software that depended on that no longer available version of a package.
If a user were to try to install a package and the specific required version of the dependency had been tombstoned, the user would be informed that the dependency is no longer available.
Proposed technical implementation details
No response