[Rpm-maint] [rpm-software-management/rpm] RFE: rpm without database (#1151)

Neal Gompa (ニール・ゴンパ) notifications at github.com
Sat Apr 4 16:55:51 UTC 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200404/66a4336c/attachment.html>


More information about the Rpm-maint mailing list