Chris, apologies for the late reply. On Mon, 2021-12-13 at 13:02 -0500, Chris Murphy wrote: > On Mon, Dec 13, 2021 at 10:07 AM Lukáš Hrázký <lhra...@redhat.com> wrote: > > > > On Fri, 2021-12-10 at 17:08 +0100, Daniel Mach wrote: > > > > I understand your point about auditing, but does DNF have to handle > > > everything? > > > There should be better options of tracking filesystem rollbacks than > > > DNF's history database. > > > > > > > Maybe, but the history DB still contains a log of events as they > > happened over time, I don't think that belongs to /usr. > > How about: > > For read-write /usr store any database describing /usr state in > /usr/lib/sysimage > For read-only /usr store any database describing /usr state in > /var/lib/dnf with a /usr/lib/sysimage symlink pointing to it > /var is always read-write so any database describing /var state goes > in /var/lib/dnf
That seems unnecessarily complex, and also: - if there's no symlink on read-only /usr/lib/sysimage, we wouldn't be able to create one - if you consider /usr and /var loosely coupled, linking from /usr/lib/sysimage to /var means the link could break any time or the content just not be what you expect anyway > This suggests that anything that can describe state, should have > separate databases for /usr and /var. I don't know to what degree dnf > touches various top level FHS directories: /var /usr /etc /home and so > on. But I wonder if the history databases should separately track the > things being touched? Note dnf only deals with installing RPMs, we have no means to track changes to particular files and thus track changes across various directories under root. My tentative conclusion from the disucssion so far is that we'll put the system state files to /usr/lib/sysimage in dnf 5 (I dislike the "sysimage" part of the path but we're not going to break the established convention I don't think). And the history db will likely stay in /var/lib. This adheres to KISS and anything more involved seems to not solve issues, only move them around while adding complexity. Cheers, Lukas _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
