[bug#33801] import: github: Support source URIs that redirect to GitHub

[Ludovic Courtès]

Arun Isaac <address@hidden> skribis:

>> We could maintain a cache of redirects, although that wouldn’t be a
>> real solution.
>>
>> Hmm, now that I think about it, shouldn’t we store the github.com URL
>> directly for these packages?  We could add a new lint check along the
>> lines of the ‘check-mirror-url’ procedure that would allow us to find
>> out which URLs need to be changed.  If we took that route, the changes
>> you made to the importer would no longer be necessary.  :-/
>
> On the other hand, if we constrain our updater predicates to not perform
> network operations, we would be restricting what we can achieve with
> updaters. For example, suppose in the future we have a cgit-updater to
> update packages hosted using cgit. The only way to detect that would be
> using some kind of network operation. The way our updaters currently
> work, we will only ever be able to properly handle centralized platforms
> like GitHub, PyPI, etc. And, that's a pity.

We can use heuristics in many cases to determine whether an updater
applies to a package; most of the time, that’s only based on the URL,
and it might also work for many cgit instances—those that have “/cgit”
in their URL.

Then again, I expect that a growing number of packages will be obtained
through ‘git-fetch’, and the updater for such a thing is trivial
(interestingly it’s not yet implemented though :-)).

So I feel like at present we don’t have strong evidence that that the
simple URL-based approach would not scale.

WDYT?

> Another solution, though somewhat inelegant and tedious, would be to add
> an `updater' field to the package specification so that the packager can
> explicitly specify what updater to use.

That could be useful to handle corner cases, but it should remain the
exception.

Thanks,
Ludo’.