> On Jan 14, 2016, at 4:38 AM, James Olin Oden <james.oden@gmail.com> wrote:
> 
> 
> 
> On Wed, Jan 13, 2016 at 12:10 PM, Jeff Johnson <n3npq@mac.com <mailto:n3npq@mac.com>> wrote:
> <snip>
> 
> Most of the applications that use an rpmdb appear to be a 1-time data scrape of an rpmdb
> (libguestfs with db_dump(1) and what has been done in yum/zypper in the past). A 1-time
> data scrape of an entire rpmdb perhaps indicates that no database whatsoever in rpm
> is what developers wish: there is no reason I know that a pile of *.rpm files cannot replace
> the /var/lib/rpm/Packages store and leave indexing to applications (which are doing the indexing
> into the data scrape already).
> 
> *shrug*
> 
> Exactly.   BTW, this sort of storage is not to far from the way nosql type databases like mongodb stores things.   You essentially store documents that are quickly retrievable, and then the indexing on the document's data is done in the application (and sometimes with another database).
> 
> Either way though it would be a shame for RPM to lose it's ACID properties.   That said the world is moving to doing rollbacks through a filesystem snapshot (which I just noted was in RHEL 7 today) so maybe ACID becomes far less important.
> 

Before we get too far off the topic of sqlite3 support on an embedded SD card with “Exactly."

I was referring to mmap’ing a header directly from a *.rpm file (which is what rpm5 currently does)
and skipping the need to copy the header blob into a Packages store entirely. That captures the static
metadata for applications, but cannot represent dynamic state like “installed” and “install time” etc.

nosql databases most definitely have indices and consistency properties far beyond the ultra-primitive
Great Big Pile Of RPM Packages store that I was suggesting. BDB was the original NoSQL database, and ACID/CAP
properties in a database are more stringent than what a file system provides even with snapshots.

Having stored blobs instead of organized key->value data has many compatibility issues which
cannot be avoided: consider MD5 -> SHA256 changes.

I’m not sure what RHEL7 claims today: BTRFS has had file system snapshots for quite some time, and RHEL is
still seeking the grail of a RO /usr, with configuration in /etc and state in /var.

And there still is the semantic issue:
	How does one upgrade content on a RO mount point like /usr?

See bugzilla #119185 …

73 de Jeff