On Thu, Jan 13, 2022, at 7:52 AM, Vít Ondruch wrote:
Actually, shouldn't rpm-ostree carry around some copy of the RPM
database, which would describe the state of /usr and once the update is
successful (or snapshot active?), merge it into the main system RPM
database? Apparently, something like this is already happening e.g. for
/etc content if I understand it correctly. Or this is the direction in
which the /boot will be handled eventually. Or possibly it could be just
some linked (possibly just read only) database.
I think you are confusing/conflating image based updates and client side snapshots (and
relatedly, client side offline updates, which is what
https://github.com/OpenSUSE/transactional-update). They are related, but different.
It's important to emphasize that rpm-ostree systems are by default, *image based*.
For example, every single Fedora CoreOS system running the latest "stable"
commit has *bit for bit identical /usr*, including the RPM database in /usr/share/rpm.
All SELinux labeling was computed server side. All %post scripts were run on the build
server.
We perform integration testing on that image before it ever hits any user's disk. See
https://github.com/coreos/fedora-coreos-tracker/issues/1066 for example. (This
integration testing aspect is not true of Silverblue or IoT, because they just ship what
bodhi ships, which is its own big problem)
If one chooses to engage client side layering (or overrides), rpm-ostree will (each time
an upgrade or change is performed) indeed regenerate the rpm database using the
"pristine" base image's version of the rpmdb.
What you are talking about seems more related to client side snapshots and/or client side
offline updates. So in your phrasing above I'd say something more like "proposed
dnf/snapper tooling" or so, and not rpm-ostree which works in a different way.
IOW, imagine, that we still keep the system read/write RPM database
in
/var and we teach RPM to use additional database(s). So RPM would know
that there might be some additional database e.g. in /usr/var/ ... The
system database would not know nothing about content of /usr, but once
/usr was mounted, `rpm -q` would provide the information from the linked
RPM database.
I am having trouble understanding what you are thinking here. If you are interested in
this, I'd recommend taking some time trying out an existing system that is doing some
of these things; either an OpenSUSE transactional-update system or an rpm-ostree system
for example.