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.
_______________________________________________
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
