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 work.
This is probably best tracked in https://github.com/coreos/rpm-ostree/issues/1964