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

[Panu Matilainen]

On 12/14/21 22:59, Colin Walters wrote:
> 
> 
> On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote:
> 
>>> The change is not so simple. It is not only the movement of files from one location to another one. We store more types of data in that location - history database (sqlite), module failsafe data (yamls). In future we will store system state data (toml). Data is not only modified after RPM transactions but also by module and mark commands. What I want to say is that the change will be painful but in the proposal there are limited benefits.
> 
> When the rpmdb was bdb and not extensible, I understand the idea of dnf having its own separate database.  But I don't understand why there are two separate sqlite databases now.

The rpmdb is not hard-wired to sqlite. Also, whatever the format used 
it's strictly private to rpm except what's exposed through librpm APIs. 
So it's certainly NOT extensible in the sense that anybody wanting to 
put something package related there is free to do so.

> 
> Anyways, a lot going on here and rather than point by point I'll say basically:
> 
> It'd be great from the rpm-ostree PoV to have a shared consistent place for the rpmdb.  Last time this came up I think Panu really wanted to get the sqlite change out first, which - fair.  But now that's done, so are there any other blockers?

Just the pain and misery of dealing with a fundamental change that has 
zero benefit to rpm itself. It'll be a long, long, long time before 
/var/lib/rpm is phased out of existence for good, and in the meanwhile 
us rpm f get to answer all the questions and complaints about it. I'm 
not looking forward to that.

	- Panu -

> 
> We could try simply not changing existing systems in-place at first, but just do it for new installs, add the backcompat symlink, ensure the stack looks in both places (preferring new); that's actually mostly done AFAIK.
> 
> Today rpm-ostree has its own state management that doesn't use the libdnf history stuff.  Longer term it would be good to have a unified vision there - most of this is touched on in https://github.com/coreos/rpm-ostree/issues/2326
> 
> But I think I'm arguing to decouple the rpmdb move from the dnf move.
>