[LEDE-DEV] [PATCH] scripts/download.pl: Use CDN for kernel downloads

[Arjen de Korte]

Citeren Bjørn Mork <bjorn at mork.no>:

> Felix Fietkau <nbd at nbd.name> writes:
>> On 2016-05-23 12:29, Petr Štetiar wrote:
>>> Felix Fietkau <nbd at nbd.name> [2016-05-23 11:11:50]:
>>>
>>>> On 2016-05-23 10:29, Bjørn Mork wrote:
>>>> > Petr Štetiar <ynezz at true.cz> writes:
>>>> >
>>>> >> -			push @mirrors, "https://kernel.org/pub/$dir";
>>>> >> +			push @mirrors, "https://cdn.kernel.org/pub/$dir";
>>>> >>  			push @mirrors, "ftp://kernel.org/pub/$dir";
>>>> >
>>>> > Not sure that is a good idea at this point.  At least here, kernel.org
>>>> > has IPv6 AAAA records while cdn.kernel.org does not:
>>>>
>>>> So why not add both? :)
>>>
>>> If I understand it correctly, the code is going to use another  
>>> mirror only if
>>> the current mirror fails. In my case the download was awfully  
>>> slow, but didn't
>>> failed.
>> You could put the CDN first, and the regular kernel.org afterwards.
>
> Sounds like a good solution.
>
> As for reporting this problem to the kernel.org admins:  I'm pretty sure
> they are aware of the issue, and they do provide both URLs so it's not a
> showstopper. I just wanted to point out the regression *replacing* the
> dual stack URL would represent in OpenWrt.  Using both, with the CDN
> being tried first, gets the best of both worlds

Since GitHub apparently also uses Fastly as CDN provider, building on  
a machine with IPv6 only connectivity is going to be difficult anyway.  
Using both won't hurt, but if you're not able to connect to an IPv4  
server for the kernel sources, you'll likely run into similar problems  
for pretty much everything else too.

> Until the CDN is dual stack, which is bound to happen sooner or later.
>
>> Also, I think you could probably get rid of ftp://kernel.org while we're
>> at it. FTP is a horrible protocol and if HTTP fails, FTP is even more
>> likely to fail.
>
> Maybe someone is preferring ftp because of the cacheability?  Or maybe
> not...
>
>
> Bjørn
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev