Dne 13. 01. 22 v 15:26 Colin Walters napsal(a):
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.
I think you are doing unnecessary difference between those.
In my view, there is no difference if /usr is read-only, network
mounted, expanded from tarball or managed by rpm-ostree. The point is
that the location, while being available on the user system, is not
modifiable by RPM. The only requirement is that RPM is be able to
provides metadata about that location. In this case, it makes perfect
sense if the /usr contains some metadata in RPM consumable format (be it
RPM database, but that is technical detail, because it could be its
simpler version for RO filesystems).
Now should there be different locations really managed by RPM, such as
/opt, there is no reason why there should not be the system RPM
database, which would store location about that parts of the system. To
cover this scenario for rpm-ostree, there needs to be done something
complex, in your words:
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.
And I say this is wrong concept (understandably given by technical
limitation). RPM in this case should keep using its system database and
understand that /usr was delivered by different means, it can't manage
the /usr content, but there is the metadata available.
In this case, when the base image was updated, the RPM database would
not need to be regenerated. However, the base image update could be
clocked when e.g. RPM discovered, that it would broke the system
dependencies.
Vít