This would essentially make it so rpm can behave the same way dpkg does, and
opens us to the same problems dpkg has:
* People can and will randomly manipulate files to force the package manager to
do weird things (it's even documented in various troubleshooting guides)
* It is not possible to atomically update package information, nor provide any
transactional qualities. This means also it's possible to have races all over
the place, depending on filesystem and OS semantics.
I don't think it's a bad idea to provide a way to export this, but I wouldn't
think of it as a good idea to make rpm _rely_ on it. Also, with the exception
of ndb, pretty much all rpm backends have been externally introspectable. So
unless you're using ndb, you're usually able to at least read the database
without rpm.
I also don't think the binary blob "issue" is particularly compelling for the
container case, because container images and their layers are almost entirely
made of binary blobs. If this hasn't been optimized for already, people are not
doing their jobs well. 😜
And the potential benefit of moving it back into `/var` (which, to be clear, is
only an issue on RPM-OSTree and SUSE distributions) is negated by the fact that
we'd _still_ need stuff in `/usr/lib/sysimage/rpm` to rely on. But we'd wind up
with a state synchronization problem on top of it, which just makes everything
worse.
So in the end, I'm not sure this is a good idea.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1151#issuecomment-609057625
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
