[pacman-dev] [PATCH] Add config var to limit repo connection timeout
New ConnectionTimeout variable sets the amount of time trying to connect
to a repository, before timing out and trying the next one.
Signed-off-by: Nathan Aclander
On 7/4/19 7:47 am, Nathan Aclander wrote:
New ConnectionTimeout variable sets the amount of time trying to connect to a repository, before timing out and trying the next one.
Signed-off-by: Nathan Aclander
We currently have the ability to wait 10 seconds or forever. I don't think more fine grained controls are needed. Allan
I'm fairly new to using git send-email, so I wasn't sure how to add an explanation to the patch while cleanly separating it from the git commit message. I can speak more to why I found it useful. While I was traveling, certain mirrors became unreachable, or extremely slow. I had to wait 10 seconds not only for each repo, but then again every time pacman would try and download an individual package. Since this was set at 10 seconds by default, the wait time was far too long. I wanted to change it to 1 second so that pacman would move on to the next mirror faster. Using this patch seemed more usable for me than to having to comment out mirrors manually depending my network conditions. Are you concerned that having this parameter be tunable would cause pacman.conf to be too complex? Nathan
On 04/06/19 at 04:43pm, Nathan Aclander wrote:
I'm fairly new to using git send-email, so I wasn't sure how to add an explanation to the patch while cleanly separating it from the git commit message. I can speak more to why I found it useful.
Use --annotate and put comments you don't want to end up in the log between the diff stats and the first 'diff --git' line: --- doc/pacman.conf.5.asciidoc | 3 +++ 8 files changed, 24 insertions(+), 1 deletion(-) <--- Comments go here. diff --git a/doc/pacman.conf.5.asciidoc b/doc/pacman.conf.5.asciidoc
While I was traveling, certain mirrors became unreachable, or extremely slow. I had to wait 10 seconds not only for each repo, but then again every time pacman would try and download an individual package. Since this was set at 10 seconds by default, the wait time was far too long. I wanted to change it to 1 second so that pacman would move on to the next mirror faster.
Using this patch seemed more usable for me than to having to comment out mirrors manually depending my network conditions. Are you concerned that having this parameter be tunable would cause pacman.conf to be too complex?
More or less, yes. We don't want to have to implement every single option that libcurl provides in pacman, so we try to require a fairly compelling justification before adding them. We are not against making network operations more configurable, though. In fact, we would like to get rid of the external downloader, but can't because some people need specific settings that we don't, and never will, expose directly. So, if you, or anybody else, can come up with a more general solution that doesn't require us to add dozens of options to pacman.conf, we'd love to hear it.
On Sun, 7 Apr 2019 at 21:02, Andrew Gregory
On 04/06/19 at 04:43pm, Nathan Aclander wrote:
Using this patch seemed more usable for me than to having to comment out mirrors manually depending my network conditions. Are you concerned that having this parameter be tunable would cause pacman.conf to be too complex?
More or less, yes. We don't want to have to implement every single option that libcurl provides in pacman, so we try to require a fairly compelling justification before adding them. We are not against making network operations more configurable, though. In fact, we would like to get rid of the external downloader, but can't because some people need specific settings that we don't, and never will, expose directly. So, if you, or anybody else, can come up with a more general solution that doesn't require us to add dozens of options to pacman.conf, we'd love to hear it.
I ran into the same objections when I wanted to expose a curl option (in my case for client certificate authentication). But maintaining a patched pacman seemed like too much long-term work, so instead I made curl-inject-opt [1], a program using LD_PRELOAD to inject curl options into sessions of another program. I also added it to the AUR [2]. It's not nearly as user friendly as a native pacman configuration option would be though: $ sudo curl-inject-opt --connect-timeout 1000 pacman -Syu You could put that in a wrapper script of course. You can even call the wrapper `pacman` and put it somewhere in your PATH (if you specify the real pacman by absolute path). It also currently doesn't come close to supporting all CURL options, but the goal is to support all sensible CURL options. So if you need one that's missing, issues or pull requests are welcome. I just added --timeout and --connect-timeout :-) [1] https://github.com/de-vri-es/curl-inject-opt [2] https://aur.archlinux.org/packages/curl-inject-opt
On 04/06/19 at 04:43pm, Nathan Aclander wrote:
I'm fairly new to using git send-email, so I wasn't sure how to add an explanation to the patch while cleanly separating it from the git commit message. I can speak more to why I found it useful.
Use --annotate and put comments you don't want to end up in the log between the diff stats and the first 'diff --git' line:
Thanks, I will make sure to do that in the future.
More or less, yes. We don't want to have to implement every single option that libcurl provides in pacman, so we try to require a fairly compelling justification before adding them. We are not against making network operations more configurable, though. In fact, we would like to get rid of the external downloader, but can't because some people need specific settings that we don't, and never will, expose directly. So, if you, or anybody else, can come up with a more general solution that doesn't require us to add dozens of options to pacman.conf, we'd love to hear it.
I'm not sure how to getting rid of an external downloader would solve the problem. Giving people the option to tune download options ( or any options ) would always result in a larger configuration file no? At best, we could stick all the curl options together in a block in pacman.conf to improve readability. I'm of the opinion that exposing more curl options is great, as long as pacman.conf remains organized. Supporting every single option is of course silly, but I thought Connection timeout would benefit enough people since it saved me from having to wait over 2 minutes for pacman to finish an update. I guess in the end it's a compromise between maintainability, customizability, and user-friendliness. Nathan
Maarten de Vries
I ran into the same objections when I wanted to expose a curl option (in my case for client certificate authentication). But maintaining a patched pacman seemed like too much long-term work, so instead I made curl-inject-opt [1], a program using LD_PRELOAD to inject curl options into sessions of another program. I also added it to the AUR [2].
That looks great, and would definitely solve my problem. Like you said, it's not the most user-friendly solution. I wish it be baked into pacman just so I don't have one more thing to set up the next time I reinstall Arch. Nathan
participants (4)
-
Allan McRae
-
Andrew Gregory
-
Maarten de Vries
-
Nathan Aclander