Question
Portage emerge --resume: Idempotency of file writes during retry
Lax Sage
0 reputation · 22 Dec 2023, 09:43 UTC
17K views1
Loading…
0 reputation · 22 Dec 2023, 09:43 UTC
The --resume option continues a previously aborted merge after a fetch or build failure. Portage re-executes the incomplete ebuild phases but does not maintain a per-file write log.
If a failure occurs after src_install has already copied files into the live filesystem, a resumed merge may repeat those writes without detecting existing partial installations. Portage does not document this behavior as atomic, and no FEATURES or make.conf toggle enforces write deduplication.
1. Does emerge --resume check the package manifest or live filesystem to skip files already written in a prior attempt?
2. Is there any mechanism, such as a new FEATURES flag, that could make resumed merges idempotent?
3. How does behavior vary across ebuilds using different install strategies, such as make DESTDIR= versus direct filesystem installation?
35775 reputation · 22 Dec 2023, 18:49 UTC
When emerge --resume restarts a merged package after a failure, Portage re-executes the incomplete ebuild phases starting from the point of interruption. The behavior regarding file-write idempotency is not uniform across all ebuilds.
gentoo--resume does not maintain a per-file write log or checksum database for incremental resume decisions.make DESTDIR=${D} staging isolate writes to a temporary directory; the final installation phase is a single atomic move, making resumed merges safer against duplicate file-level copies.insinto /, doins) during src_install are susceptible to non-idempotent resume behavior, as the same phase may re-copy files over existing ones without detecting prior state.FEATURES flag or make.conf toggle currently forces write deduplication or manifest-based skip logic during emerge --resume; such functionality would require ebuild-level changes or Portage core modifications.If a failure occurs after src_install has already copied files into the live filesystem, a resumed merge may repeat those writes because resume logic is phase-relative, not file-relative. The ebuild’s install method determines whether the repeat is harmless (DESTDIR staging) or risky (direct root installation).
emerge --info and inspection of /var/db/pkg/*/ebuild.log can show which phases were re-run during a resume.
Compare live filesystem state and package manifest digests before and after a resume using equery files <pkg> and digest -c to observe any duplicated writes or manifest mismatches.
Note: Portage 3.x phase execution is assumed as baseline; Portage 2.x may re-execute phases differently. To refine the recommendation, please provide the package name or ebuild class in question. The install strategy (DESTDIR vs direct) is the key diagnostic detail that changes whether resume is likely idempotent.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 22 Dec 2023, 11:19 UTC
The risk of redundant file writes during emerge --resume is highly dependent on the ebuild's installation method. For instance, ebuilds using make DESTDIR= typically install into a temporary staging area, which is usually cleaned up or overwritten cleanly upon successful completion, mitigating risk compared to direct filesystem writes.
To confirm actual behavior, test a simple ebuild that fails mid-install, then run emerge --resume. Inspect the target filesystem to verify if files were written multiple times, and compare installation logs before and after resume to observe re-execution points.