> On Jan 12, 2016, at 3:06 PM, Tim Mooney <Tim.Mooney@ndsu.edu> wrote:
> In regard to: Re: RPM sqlite3 support, Jeffrey Johnson said (at 12:46pm on...:
>> The sqlite3 code (and support) in rpm5 was abandoned in favor of
>> Berkeley DB ACID transactional support quite some years ago
> I've been meaning to ask about this for a while, and this provides a
> good segue...
> With Oracle's license change on BDB 6.x (or 12.x, or whatever they're
> calling it) to AGPL, does that impact rpm5's long-term use of BDB?
No impact for the project, but thereâs always users who want/need different.
BDB been doing the job for RPM (and many many other projects) since forever.
Thereâs little engineering reason to change.
(aside since its sure to be mentioned)
MDB could be adapted to RPM. The usage cases for OpenLDAP and RPM
are rather different, where OpenLDAP is a âlightweightâ well defined schema server,
while rpm saves a header blob under an index with secondary lookup.
The sqlite code wasnât very difficult and could be resurrected. The problem is/was one of design:
the sqlite3 code mimicked the BDB vectors with a primitive schema. What users are
expecting with SQL is a much richer schema. There was a very clever implementation
done at carb.org years ago that built schema du jour indices by internalizing rpm âquery
in postgres and rebuilding tables as needed. The usage case there was web queries,
which are a very different application than doing install/remove (which are essentially just bulk
From an engineering POV, remapping the Packages store to a heap, possibly remote, or
possibly into an offset in the original package, might be useful if secondary lookup is
The next step to alternative Package stores would be to switch the package index from uint32_t
to 128 buts and use a UUID instead.
73 de Jeff
> Tim Mooney Tim.Mooney@ndsu.edu
> Enterprise Computing & Infrastructure 701-231-1076 (Voice)
> Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
> RPM Package Manager
> User Communication List email@example.com
Received on Tue Jan 12 22:40:50 2016