On Thu, Mar 26, 2020, at 8:35 AM, Zbigniew Jędrzejewski-Szmek wrote:
Relying on the target distro management stack sound nice, but is
actually problematic: how do you run the next version before you
install the next version? Sure, you can install stuff to some temporary
location and run the tools from there, but then you are running in
a very custom franken-environment.
This is exactly what rpm-ostree does - it always makes a new rootfs (hardlinked) and runs
scripts in there (using bubblewrap).
Such a mode of running would face
the same issue as anaconda installer: it would only get tested during
the upgrade season, languishing otherwise.
You have correctly identified the rationale behind why rpm-ostree works the way it does.
Every single upstream commit and every Fedora CoreOS release is gated on this working.
However, we have the opposite problem in that extending this model to supporting live
updates *and* this is hard: https://github.com/coreos/rpm-ostree/issues/639
As far as the database transition...today rpm-ostree generates the rpmdb server side by
default, and updating it is a transactional operation (along with the rest of the
transaction) so dunno, I guess at some point we'll just flip the default build-side.
We may need to make it a build-time option. It would be most ideal if Fedora N-1 at least
supported reading from the new format, because if e.g. one does an upgrade, then e.g. the
desktop a11y stack happens to be broken and you roll back, the old rpm-ostree may fail to
parse the RPM database in the new deployment root. Although, if the new rpmdb is in a
different place, then maybe it will just appear to be nonexistent and I *think* that would
This is probably best tracked in https://github.com/coreos/rpm-ostree/issues/1964