On Fri, 2021-12-10 at 17:08 +0100, Daniel Mach wrote: > On 10. 12. 21 13:39, Lukáš Hrázký wrote: > > On Fri, 2021-12-10 at 06:16 -0500, Neal Gompa wrote: > > > (Adding the correct Daniel Mach email address, he moved from Red Hat > > > to SUSE last month...) > > > > > > On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <li...@colorremedies.com> > > > wrote: > > > > I'm pretty sure I'm generally opposed to the idea of logs being rolled > > > > back (in a snapshot and rollback regime). Logs should always carry > > > > forward. Ideally, indicate relevant things like rollbacks in the log, > > > > because rolling back a log is a form of data loss. The history > > > > database sounds more like a log than not. So I'm getting squeamish > > > > about locating that somewhere else. Whereas system state information, > > > > if it's primarily describing /usr, sounds like it needs to get > > > > somewhere in /usr. > > > > > > > The history database is basically a transaction database like the > > > rpmdb is. It maps rpmdb transactions to dnf actions. > > I'm not sure this is true at all. I haven't examined the rpmdb ever, > > but AFAIK it contains the list of currently installed rpms (and their > > data), but not the history as they came and went (i.e. a log). > > > > OTOH dnf history database is exactly that. The current system state is > > in dnf 4 also computed as the aggregation of the transactions in the > > history database, which is IMO very wrong and we're fixing it in dnf 5. > > > > > So if you're > > > rolling back the rpm-managed content, it still makes sense to roll > > > back the history database, since that's the state of the system. It's > > > not terribly useful if the matching rpmdb transactions don't exist in > > > the rpmdb. > > Conceptually I agree with Chris on this: We shouldn't roll back the log > > of transactions if we'd be rolling back the system itself. That way you > > in effect erase that the system was running in a different state for an > > amount of time, imagine an auditing situation. > > As a user, I wouldn't expect history db to contain transactions that are > not relevant to my system. > If I do filesystem rollback, I'd probably want to rollback even the > history db. > Also, if we don't rollback history db too, it's going to break `dnf > history rollback` functionality. > > 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. > > There are also issues with sqlite creating some lock files even if just > > reading, which wouldn't be possible on a RO FS (IIRC how it was > > explained to me), so there are other reasons why the history db will > > likely not move to /usr. > If it's the same location where rpmdb is supposed to live, it's probably ok. > AFAIK its rw when you change the image and ro when you use it. > > > > > That said, the dnfdb is only *important* to move because it's required > > > for modularity stuff to work properly. Otherwise, it's not a huge deal > > > one way or another. > > Please don't introduce dnfdb as a term, AFAIK it doesn't exist :P > > > > If there's anything in history db that is required for modularity to be > > functional on a system, it should be moved to the dnf system state (in > > dnf 5), history db should just be a log and nothing else (at most we > > could use it to reconstruct the system state if it gets damaged while > > the history db remains intact). > It's mainly comps that lives nowhere else than in history db - and this > must be fixed by introducing "@System" (== installed) data for comps. > Modularity mainly relies on data in /etc, but it is similar problem to > comps above. > Even more importantly, history DB now contains the list of userinstalled packages (which also lives nowhere else). _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
