[Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr

[Lukáš Hrázký]

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 <lists at 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.

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.

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

Cheers,
Lukas