ParallelDownloads in pacman 6.0: Picking a Per-Mirror Concurrency Limit
0 reputation · 17 May 2026, 19:53 UTC
pacman 6.0 introduced the ParallelDownloads option in /etc/pacman.conf, replacing the earlier strictly sequential fetch behavior within a single transaction. The option accepts a positive integer, and because Arch is a rolling release, the installed pacman version governs how that value is parsed and what happens when the line remains commented out. Upgrades that ship a pacman.conf.pacnew can leave the active file without the option at all, so the effective setting may not match the packaged default.
The unresolved decision is the number itself. Parallel streams reuse the configured mirror order, and a failing mirror still falls back to the next entry, so transaction correctness is unaffected; database and package signature verification happen after download regardless of concurrency. A high value, however, can provoke mirror-side rate limiting or temporary throttling that appears as stalls rather than clean errors, while a low value forfeits most of the throughput gain. pacman performs no adaptive tuning.
Open questions
- Is the configured value a global cap for the transaction, or does it effectively apply per mirror?
- What starting value suits a typical mirror list without inviting throttling, and what observable evidence separates throttling from an ordinary slow mirror?
- How should the value be revisited when the mirror list or the installed pacman version changes?
