Re: uscan roadmap
On 02/12/2021 10:16, Yadd wrote:
On 02/12/2021 00:34, Paul Wise <pabs@debian.org> wrote:
On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote:
Personally I dislike redirectors.
A redirector service is superior to including the redirector code
within uscan itself or within a debian/watch file, since when the
upstream website breaks the existing code, a service can be updated in
one place immediately, while uscan in Debian stable will be broken
until the next point release if it gets fixed at all and one in
debian/watch requires every package using the site to get updated.
Yes but the redirector often responded with 500 codes
Another idea to have a compromise:
* uscan is released with versioned schemes (GitHub.json, sf.json,...)
* when launched, it tries to download new version from a new Debian API
(static json files)
* if no response or no new version, uscan uses its own scheme or a
previously downloaded update (verifying signature)
* if a new version is available from new redirector:
* it verifies GPG signature of new scheme
* if not OK, it warns and uses cached scheme
* if OK, it stores it with signature in ~/.cache/uscan/schemes
Then:
* no more redirector with an heavy load, but just some JSON schemes
statically stored
* uscan still works if Debian website doesn't respond
* GPG permits to be sure that scheme isn't corrupted (released files
are as protected as uscan itself because owned by root)
* easy update if upstream store changes its behavior: just to update
one JSON file
What do you think about this idea? Which GPG keys will be accepted?
More than one scheme could be used. Example:
Schemes: GitHub, stable
Schemes: GitHub, semver
GitHub scheme:
{
"Version": "1.0",
"filenamemangle": "auto",
"regex": "archive/.*/v?(@DEFAULT_VERSION_REGEX@)@ARCHIVE_EXT@$",
...
}
"stable" scheme:
{
"Version": "1.0",
"Default-Version-Regex": "(?:0|[1-9]\d*)(?:0|[1-9]\d*)*"
}
Reply to: