On Jan 13, 2016, at 6:34 AM, devzero2000 wrote:
>
> On Tue, Jan 12, 2016 at 10:06 PM, Mark Hatle <mark.ha...@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
>
