On Dec 9, 2009, at 5:20 AM, devzero2000 wrote:

> On Tue, Dec 8, 2009 at 4:21 PM, Jeff Johnson <n3npq@mac.com> wrote:
>> 
>> So what issues are there with continuing (or removing) the existing sqlite3
>> support @rpm5.org?
> For @rpm.org is easier to remove something that has never been used by
> distributions that use that code base, which now seems destined to be
> at most Linux platforms. This seems quite different for RPM5. It 'also
> true that SqlLite support has always been considered experimental for
> what i know, but perhaps i am wrong. The (simple) considerations that
> come to mind:
> 
> - What is useful to have more of an implementation of a DB backend today?

What is "more of an implementation"?

Adding a different database backend to RPM is largely the same as
always, there are essential open/close/get/put/del and cursor
open/close methods that need to be written. There's a handful
of other methods I've added, perhaps exists and count are the most important.

But what you are likely seeking is the ususal compile/exec SQL framework.
Methods could be added for compile/exec, but then 2 types of rpmdb access
would need to be supported in parallel.

SHow me a usage case and I'll add other databases after Berkeley DB ACID
is in place.

> - How many today use on other platforms RPM5+SqlLite? Maybe only on
> some QNX, for berkeley DB problem con qnx nmap, but on recent qnx
> perhaps the problem is not such severe anymore
> http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/build_unix_qnx.html.
> But i not use qnx so perhaps I have not the right info in this area.
> 

QNX and WindRiver and (to some extent) Apple are the Sqlite users.

73 de Jeff