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. _______________________________________________ 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
