For the record, I obviously support this change. Responding to a few threads: On Wed, Dec 29, 2021, at 10:16 AM, Peter Robinson wrote: > How does this work on RO /usr files systems? I thought data in /usr > was supposed to be static/ It works for rpm-ostree because it's > updated at tree creation time. I think you know this but it's worth elaborating on here; rpm-ostree supports client-side layering (and overrides too) and even live updates - and those all operate by default while maintaining `/usr` read-only from the perspective of the rest of the system. The way this works ultimately is quite simple; the underlying filesystem is writable, we just remount it writable *in a private mount namespace*. So even when you do e.g. `rpm-ostree install -A usbguard`, there is no point where *other* processes can write. People are focusing a bit too much on "read-only" in this thread - it's more about "lifecycle binding" and versioning the binaries together with metadata about the binaries. On Thu, Dec 30, 2021, at 1:57 PM, Chris Murphy wrote: >> What happens if /var/lib is read-only? Changing (fixing?) this would >> be a pre-requisite to this proposal, we don't want 'dnf list' to break. Why would /var/lib be read-only, but /usr be writable? > Why should it be a prerequisite? In all Fedora editions and spins with > dnf, /usr and /var are read-write. In the case of rpm-ostree based > editions and spins, they don't include dnf. Remember rpm-ostree links to libdnf, and significant code is hence shared. That's part of the ASCII-art architecture diagram in the docs https://coreos.github.io/rpm-ostree/ The way I'd say this is it aligns "traditional" dnf systems with what rpm-ostree has been doing for many years now, and that will help share *even more* code and logic in the future. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
