rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

Frank Ch. Eigler fche@redhat.com
Thu Dec 19 00:47:00 GMT 2019


Hi -

> The code looks good in general, do note that if you rebase/squash to
> onto master there is a slight conflict with the curl_res/curlm_res
> fixlet. Since GCC10 isn't out yet, just yell if this gives you trouble
> and I do/test it for you.

I'll figure it out and merge.


> [...]
> I would add something like:
> 
>   /* Make sure there is at least some progress,
>      try to get at least 1K per progress timeout seconds.  */
>   curl_easy_setopt(curl, CURLOPT_LOW_SPEED_TIME, 5 * 1024L);
>   curl_easy_setopt(curl, CURLOPT_LOW_SPEED_LIMIT, progress_timeout);
> 
> The idea being that if we didn't at least get 1K per 5 seconds then the
> connection is just so bad that it doesn't make sense to wait for it to
> finish, since that will most likely be forever (or feel like it for the
> user).

The problem with that is that, for a large download such as a kernel,
it can take almost a minute to just decompress the kernel-debuginfo
rpm far enough to start streaming the vmlinux file.  (In the presene
of caching somewhere in the http proxy tree, it gets much better the
second+ time.)  So any small default would be counterproductive to
e.g. systemtap users: they'd be forced to override this for basic
usage.

- FChE



More information about the Elfutils-devel mailing list