On Jul 31, 2007, at 3:32 PM, Thomas Lotterer wrote:

> On Tuesday, 31. July 2007 at 3:04 pm, Jeff Johnson wrote:
>> On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
>>> On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson wrote:
>>>> On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
>>>>> Decision:
>>>>> - exclusively use Berkeley DB
>>>>
>>>>     3) NFS support
>>>>
>>> This 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.
>>>
>> I don't disagree. However, an answer for client/server rpmdb needs to
>> be identified.
>>
> No use case for client/server rpmdb has been brought to my attention.

Client/server rpmdb is tied to an AutoFu switch to enable sunrpc for the
necessary sunrpc server to remote an rpmdb.

A usage case is on the rpm-maint mailing list, which also points
(exactly the same person who originally requested years ago) the
ability to put an rpmdb remotely on an NFS server.

Also in the rpm-maint msg is a ptr to a msg describing how to set up
a remote rpmdb on a NFS server using sunrpc. Ironically I now deal  
with the
same remote NFS server daily several years later ...

>
>> There is sunrpc, and there is sqlite, are the current answers.
>>
> Note SQLite is not an answer for NFS support because it suffers  
> from the
> described locking vs. hang problem. As far as I remember, RPC has
> exactly the same problem. A timeout proves me wrong but anyway, this
> would mean to turn RPM into a client/server application and this would
> mean the server using BDB. Finally, no architectural change.
>

Heh. Putting _ANY_ data you care about on NFS is asking for trouble,
its not just fcntl lock transport. No matter what, NFS has the  
occaisonal
hiccup, usually unnoticed. That's my experience over the years, ymmv.

Linux NFS, as NFS implementations go, is underwhelming too.

73 de Jeff