Re: uscan roadmap

["Andrej Shadura" <andrew@shadura.me>]

Hi,

On Thu, 2 Dec 2021, at 11:36, Yadd wrote:
>>> 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?

I like this idea. It deals well with both non-transparency of redirectors running elsewhere and verbosity and non-updateability of hand-written patterns.

-- 
Cheers,
  Andrej