On Jun 8, 2007, at 6:01 PM, Michael Jennings wrote:

> On Friday, 08 June 2007, at 17:55:04 (-0400),
> Jeff Johnson wrote:
>
>> You mean like dpkg does?
>
> I don't know how dpkg does its stuff. :)
>
>> Nothing. But performance, not locking, is the key issue for choosing
>> a representation of the installed package set.
>
> What about as an alternative representation, kinda like what you did,
> only on a grander (and crazier scale)?  Imagine rpmd, a user-space
> daemon which maintains a pseudo-filesystem (a la /proc or /sys)
> interface to the rpmdb.  Client programs could use rpmdb via rpmlib or
> the pseudofilesystem, either way.  The former for performance, the
> latter for portability and ease of development/rapid prototyping.
>

Direct access to an rpmdb requires locking, and shared read locks
are a DoS for exclusive write locks, and vice versa, no matter what.

So custom automagic exports avoid the locking issues associated
with direct access to an rpmdb. Note that other locking issues
are possibly introduced because the export/update may have
issues with whatever some application desires, but at least the locking
is finer grained, with less contention, than having every application
competing for rpmdb access.

> And you thought your del.icio.us idea was nutty.  ;-)
>

;-)

So what's nutty about using del.icio.us instead of rpmfind.net?

73 de Jeff