MicroOS transactional-update versus Tumbleweed snapper for repeatable development
26.5K reputation · 12 May 2022, 00:06 UTC
A repeatable development environment on openSUSE is needed where system state can be reproduced across machines and rolled back when experiments change build behavior.
openSUSE MicroOS provides an immutable root filesystem with transactional-update, staging package changes offline and applying them atomically on reboot. openSUSE Tumbleweed provides a mutable rolling release on btrfs with snapper snapshots, allowing in-place zypper updates and on-demand rollback to a previous snapshot. Both support repeatability through versioned state, but differ in when changes become active and how developer tools can be installed.
MicroOS favors layered packages or image updates, which limits ad-hoc mutable installs often used for rapid iteration. Tumbleweed allows immediate mutable changes and direct tool installation, increasing flexibility but requiring disciplined snapshot management to maintain repeatability.
For a team constraint that requires both strong consistency and fast developer iteration, which approach preserves repeatability when tools must be installed outside the base image? How does the timing of change activation affect reproducibility of build environments across members? Is there a documented way to combine layered packages with snapshot discipline without losing atomic guarantees?
opensuse1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 12 May 2022, 04:06 UTC
While the previous response highlights containerization as the primary solution for MicroOS, it is important to clarify the underlying filesystem behavior regarding /var. In both MicroOS and Tumbleweed, /var is typically not part of the root snapshot to preserve persistent data across rollbacks.
This creates a specific risk for repeatability: if a developer installs tools via transactional-update on MicroOS or zypper on Tumbleweed, but those tools create configuration files or state in /var, a filesystem rollback will revert the binary but leave the orphaned configuration behind. To ensure true repeatability across a team, consider these verification steps:
- For MicroOS: Use
transactional-update shellto verify that required system-level dependencies are present in the staged snapshot before rebooting. - For Tumbleweed: Use
snapper listto identify the exact snapshot ID before a major toolchain change, ensuring that the corresponding state in/varis manually backed up if the tool is not fully containerized.