On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson <n3npq@mac.com> wrote:
> On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
>> Decision:
>> - exclusively use Berkeley DB
> 
> I'd change "exclusively" to "primarily". Otherwise we have an
> external feature regression.
> 
That's exactly the intention! My observations are there is not enough
interest in supporting a different DB. The current incomplete support
for SQLite sends a false signal to those who are interested in it.
Everyone should know for sure: BDB only.

> The engineering issues wrto a SQL db should be addressed. No matter
> what, a reference SQL schema for rpm package metadata has been needed
> for years. Candidates are [...] Rolling a SQL schema from scratch is
> not impossible either.
> 
Can be done later if "Reasons" are reviewed and found to be obsolete.

> Alternatives to Berkeley DB for the 3-4 usage cases:
>     1) licensing
> 
What's the issue here?

>     2) embedded and -NPTL locking (although fcntl with BDB likely  
> addresses)
> 
So BDB is fine.

>     3) NFS support
> 
The can be rewritten to "networked filesystem support". BDB, SQLite and
any embedded DB require proper filesystem locking. Given the
environmental issues of a networked filesystem this will never work
reliably. Many NFS admins have disabled locking to avoid client hangs on
server outages and the price is obviously that locking doesn't work. If
they would use locking then this problem is gone at the price of
unpredictable client hangs. I spent years of my life trying to improve
DOS/Windows applications with embedded DB like M$ Access in networked
environments using CIFS and NCP - no way to ever fix 'em through
filesystem access. The only real fix is to use applications that are
designed for client/server environments. If rpm is ever split into a
client/server application then the server still is likely to use BDB.

So 2) and 3) do not qualify for a BDB alternative.
Let's see what 1) brings up.

-- 
http://thomas.lotterer.net