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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
