[pacman-dev] Default XferCommand breaks when resuming incomplete downloads on some servers

[Dave Reisner]

On Thu, Aug 18, 2016 at 05:39:35PM -0400, Quint Guvernator wrote:
> Hello all,
> 
> The default value of XferCommand (/usr/bin/curl -C - -f %u > %o) tells
> curl to try to resume downloads from a particular byte position if they
> are stopped prematurely. Not all servers support this, though, so curl
> may die with exit status 33 like this:
> 
>     :: Checking nwjs-bin integrity...
>     ==> Making package: nwjs-bin 0.16.1-1 (Thu Aug 18 00:38:19 EDT 2016)
>     ==> Retrieving sources...
>       -> Downloading nwjs-v0.16.1-linux-x64.tar.gz...
>     ** Resuming transfer from byte position 8736768
>       % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                      Dload  Upload   Total   Spent    Left  Speed
>       0 47.1M    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
>     curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
>     ==> ERROR: Failure while downloading http://dl.nwjs.io/v0.16.1/nwjs-v0.16.1-linux-x64.tar.gz
>         Aborting...
> 
> (To reproduce, grab the nwjs-bin PKGBUILD from the AUR. makepkg and kill
> the download, then makepkg again. There's gotta be an instance of this
> in community or extra, but I haven't run into any yet.)
> 
> The same could theoretically happen with FTP; the corresponding error
> code there is 36.
> 
> This raises the question: should `curl -C` be the default download command
> when we can't trust all servers to support resuming incomplete
> downloads?

It's rare that people use the external downloader. It'a also rare that
static content servers refuse continuation.

> To me, it seems that adding `-C` should be documented on the wiki under
> pacman/Tips_and_Tricks rather than being enabled by default. This way,
> users (ostensibly) understand the gotcha involved before enabling it.

...but the external downloader isn't a default either.

> There isn't much technical merit/demerit to discuss here, and there's a
> potential for bikeshedding, so maybe we could stick to "yes, I like it"
> or "no, I don't like it". It's barely a 1 LOC change.

no, I don't like it.

d