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
