|
bashdeps
Exact dependency materialization and manifest maintenance tools
|
Accepted
This ADR defines what version 1 means by a usable wget fallback backend.
The decision is intentionally capability-based. The presence of an executable named wget is not sufficient evidence that the implementation can satisfy the network bounds established by ADR-004.
ADR-004 selects curl as the preferred download backend and permits wget as a portability fallback. It also requires the acquisition layer to own a maximum of three transfer attempts and to use finite timeout controls where the selected backend exposes a supported form.
Those requirements expose meaningful differences among Wget implementations. GNU Wget supports -T for network timeouts and -t for limiting retries. GNU Wget also performs multiple retries by default, so invoking it without an explicit tries limit would make the downloader rather than bashdeps control the number of attempts.
BusyBox Wget is compile-time configurable. In particular, timeout support via -T SEC is controlled by a BusyBox feature option. A system can therefore have a wget command while lacking the timeout control bashdeps expects.
The fallback adapter needs a small capability floor that can be checked without performing a network request.
Version 1 SHALL consider wget eligible as a fallback backend only when its help surface advertises both of these short options:
The implementation MAY inspect wget --help output to establish those capabilities. The probe SHALL NOT perform a network request.
The meanings required by bashdeps are:
When the Wget backend is selected, the version 1 invocation SHALL be equivalent in substance to:
-t 1 ensures that one invocation represents one acquisition-layer attempt. Bashdeps may invoke that adapter up to three times as defined by ADR-004.
-T 120 establishes a finite backend timeout. Bashdeps SHALL NOT claim that this timeout has identical semantics across GNU Wget and BusyBox Wget. For example, a particular BusyBox implementation may apply the timeout to connect and read operations without providing the same DNS or total-transfer timing semantics as GNU Wget.
If curl is absent and an installed wget does not advertise the required controls, bashdeps SHALL treat the downloader capability as unavailable and return the public capability failure status defined by ADR-007.
If an eligible Wget backend is selected but an HTTPS retrieval later fails due to DNS, connection, TLS, HTTP, timeout, or transfer failure, the operation SHALL return the acquisition failure category rather than silently weakening the backend policy.
Mandatory SHA-256 candidate verification remains unchanged and remains the authority for artifact byte acceptance.
This maximizes nominal compatibility but cannot preserve the timeout and retry contract. Command presence is weaker evidence than capability detection.
GNU Wget may perform many retries by default. That would make one bashdeps attempt expand into an implementation-dependent number of backend attempts and would contradict the bounded acquisition model.
This establishes a timeout but still loses control of the attempt count. Both controls are required.
An external watchdog could bound some implementations that lack -T, but it would introduce another runtime dependency and would not solve backend-managed retry counts by itself.
Product identity is less useful than the capabilities bashdeps actually needs. BusyBox features are compile-time configurable, so identifying a binary as BusyBox does not prove timeout support.
A live probe could test actual HTTPS behavior, but backend selection would then create network traffic before artifact acquisition and would make deterministic testing more difficult. Version 1 uses a local help-surface probe and treats actual HTTPS failures as acquisition failures.
A capable GNU Wget or BusyBox Wget can serve as the fallback downloader without requiring curl.
A minimal BusyBox Wget build that lacks the required controls will be rejected as unsupported even though wget exists. That is an intentional fail-closed compatibility boundary rather than an assumption that all Wget implementations are equivalent.
The synchronization engine remains independent of Wget-specific flags; the capability probe and argv construction remain private adapter behavior.
Tests should model both an eligible Wget help surface and a present-but-ineligible Wget implementation.
Future evidence may justify a different capability probe or additional safe Wget forms. Any such change should preserve the bounded-attempt and finite-timeout properties rather than broadening compatibility by weakening them.
1.9.8