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