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.