[swsieber]

Ah, when I say rollbacks, I mean when you go to upgrade, you duplicate the strata (OS install), and the do everything in the new strata. Then if anything went wrong, delete the new strata and switch back to the one you branched from.

[ParadigmComplex]

Bedrock does support exactly this workflow. I do something along these lines, with the nuanced difference that I have a period of overlap where I'm using both the old and new strata around at once.

When a new major release of a non-rolling distro (e.g. Debian) is out, I make a new stratum for the corresponding release. I slowly migrate things over, a few packages at a time. If anything doesn't just-work with the new release, I can easily revert to getting the given functionality from the old one until I've made the necessary adjustments. Once I have everything working confidently with the new release, I can remove the old one.

Bedrock offers a configuration file that declares which packages should come from which stratum [0]. A section of it might look something like this:

    # e-mail
    arch:pacman isync # mbsync
    buster:apt  msmtp
    buster:apt  mutt
    buster:apt  urlview

When Debian 11 Bullseye is released, I can `s/buster/bullseye/`:

    # e-mail
    arch:pacman isync # mbsync
    bullseye:apt  msmtp
    bullseye:apt  mutt
    bullseye:apt  urlview

then try out my e-mail setup. If it works, I'm good; if not, I can revert. Once I have it working, I can move on to the next stanza in the described configuration file.

That having been said, I don't think this compares favorably to NixOS's much stronger rollback system here. It's a nice bonus for people who otherwise are interested in Bedrock.

[0] https://bedrocklinux.org/0.7/commands.html#pmm-world-file

[boomboomsubban]

You are describing one of the main reasons people use CoW filesystem's like ZFS. Snapshots make this a trivial thing you can do hundreds of times per day if for some reason you needed to.

[soraminazuki]

In that case, I wonder how much effort does Bedrock Linux put into isolating runtime state from individual stratas.

[ParadigmComplex]

I'm likely equipped to answer your question if you elaborate a bit on what you mean by runtime state. Could you provide concrete examples of things you are curious about?

The general pattern, in case it covers what you are looking for:

- By default, files/filepaths are isolated, similar to chroots/containers. Features the Bedrock Linux development team haven't taken time to work on yet usually work as they would in their native distro, but are not integrated with the rest of the system. This notably includes most things that package managers touch to keep them from fighting each other.

- Bedrock actively integrates a supported list of files/filepaths which are needed to ensure features from different distros interact transparently. The specifics here vary depending on the given feature. Over time, the Bedrock team expands the list of files/filepaths that do something to integrate across strata as solutions are found to do so without introducing conflicts.

- Bedrock purposefully eschews isolating things like processes and network namespaces. Running `htop` shows all processes from all distros. In the worst case scenario, the user can only get the given feature from one distro at a time. The most notable example here is systemd, which requires being run as PID 1; the lack of PID namespacing means a Bedrock system only has one PID 1 at a time. Switching between different distro inits usually requires a reboot.

- A stratum can be "disabled," which both kills all of the associated process and removes the runtime integration with other strata. Once this is done, it can be copied (backed up) or removed safely. The stratum providing PID 1 cannot be disabled, as Linux is not designed to run without a PID 1; to remove the PID 1-providing stratum, a user must first reboot and select another init. The `bedrock` stratum cannot be disabled, mostly because the Bedrock developers didn't put time and effort into supporting that workflow.

[soraminazuki]

I was referring to files created by various software at runtime, usually in /var. I'm assuming that rollbacks for a package management system would want to only roll back package-provided files and have the rest left alone.

[ParadigmComplex]

Ah, I now see what you mean. With the exceptions of /var/lib/dbus/machine-id and /var/run, which need to be shared for certain bits of software to communicate properly, /var is currently isolated by default. If a website is hosted at /var/www or e-mail contents stored at /var/spool/mail, a naive implementation of the rollback system swsieber described would roll back the website and e-mail as well. Bedrock can be easily configured to make such directories shared across the system and exempted from such a rollback system; hopefully any user who attempts such a workflow would catch this issue and change Bedrock configuration accordingly. I should probably investigate making such configuration default.