RPM Community Forums

Mailing List Message of <rpm-users>

Re: RPM sqlite3 support

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 13 Jan 2016 - 18:10:34 CET
Message-id: <A576BB57-3A10-4CF0-A0FE-90C7AF7EE542@mac.com>

On Jan 13, 2016, at 6:34 AM, devzero2000 wrote:

> 
> On Tue, Jan 12, 2016 at 10:06 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 1/12/16 2:06 PM, Tim Mooney 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?
> 
> I know we and many of our commercial customers has rejected BDB 6.x because of
> the change, so we've been forced to 'support' BDB 5.x.
> 
> Personally I would like to get rid of anything that has to do with BerkeleyDB,
> just to get rid of this or future license questions from customers.  (But
> unfortunately I don't know what can reasonably replace BDB.)
> 
> Hello 
> 
> FWIW, @rpm.org started a plan to replace the rpmdb format
> 
> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
> 
> Here the original announcement
> 
> http://comments.gmane.org/gmane.linux.redhat.fedora.devel/215427
> 
> Currently no details are known (to me)

There aren't many details, certainly the reasons for change are not clearly
expressed in the description:

	The current implementation of the RPM Database is based on Berkeley DB. There are doubts about the its future
	 and level of maintenance. In addition rpm's use of the database has multiple issues on its own. As a result RPMx
	 upstream is working to replace the database format with a new implementation.

The implementation (assuming rpm/lib/backend/ndb is the new format) is a rather
straightforward hash based database afaict. I am not seeing the necessary
interconversion tools between the formats, not hard to write when the time comes.
I'm also not seeing provisions for transactions and ACID and caching and
all the other sophistication/complexity that Berkeley DB provides, but
perhaps I am not appreciating the ndb implementation from a single
pass through the code.

There is also no obvious signs of remote access and/or replication. The API is
simple enough that any form of RPC will serve for remoting. OTOH, there's
much much more to replication than RPC.

The discussions are mostly legitimate concerns about compatibility and its pretty
clear that the proposed solution for other projects is
	Use rpmlib API's if you wish compatibility with an rpmdb.
Which isn't bad advice, just opposite from the entire intent of using a "standard"
API in Berkeley DB way back when so that other/better implementations than rpm
could be developed (of course the main problem there is that the Packages database
contains a header blob rather than simple/rich data types that applications/developers expect).

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*

C+ would be my grade for what I am seeing implemented in rpm/lib/backend/ndb

hth

73 de Jeff
> 
> Elia 
>  
> 
> --Mark
> 
> > Tim
> >
> 
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> User Communication List                             rpm-users@rpm5.org
> 
Received on Wed Jan 13 19:11:11 2016
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.