RPM Community Forums

Mailing List Message of <rpm-devel>

Re: 4.5 features: Automagically export package metadata

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 09 Jun 2007 - 01:26:29 CEST
Message-Id: <33C01DA4-238E-4E77-A07E-893A553DB344@mac.com>

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

> On Friday, 08 June 2007, at 18:09:07 (-0400),
> Jeff Johnson wrote:
>
>> 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.
>
> Which would also be true for the daemon.  Obviously it wouldn't be
> able to have permanent locks on the DB, but something with
> fam/imon/poll to watch for rpmdb changes, lock, update, unlock...would
> that be reasonable?
>

A read only file system presentation based on automagically (and  
synchronously)
exported custom data is rather easy to do. The directory mtime that  
contains the
export can be stamped when there is a change, so fam/imon/poll have a  
simple
event  trigger. Only the  containing directory would need to be checked.

But fam/imon/poll are perhaps overkill if all you want is to display  
some readonly
metadata in a file system like hierarchical format. The automagic  
export in
current rpm installs/erases (and exports) exactly when the package is  
registered
in an rpmdb.

Write operations for a file system presentation to trigger, say, an  
install/upgrade
would be slightly trickier. Likely the easiest implementation would be
      echo "/path/to/my/pkg*.rpm" > /rpm/install
as a means to install/upgrade a package, including all necessary  
dependencies of course.

Assuming a /rpm mounted pseudo file system based on FUSE.

>>  So what's nutty about using del.icio.us instead of rpmfind.net?
>
> I'm all for using tags as a replacement for Group: which went up a
> creek the moment other distros stopped giving two hoots about
> /usr/share/doc/rpm-4*/GROUPS.
>
> Are you also advocating using del.icio.us as an rpm search engine?
> I'm not sure how that would be better than updating rpmfind.net to use
> tags, as it is a niche engine where del.icio.us (which I'm *really*
> starting to hate typing, BTW :P) is all-purpose.
>

Not advocating, I'll leave that to the ix86/linux puppies and the  
Debian Borg.

But del.icio.us allows personal tagging, and the signal-to-noise  
ratio for
del.icio.us social tags is higher (and easier to believe) than any other
hierarchical tag format/taxonomy for content (in this case packages)
that I'm aware of.

Yah, took me a while to figger how to type del.icio.us instead of  
deli.cio.us.
I'm mostly there now.

> A delicious search on "rpm" revealed that rpm is related to "music."
> Neato. :-)
>

Don't start ;-) I dearly wish to storm Redmond and hijack the *.rpm  
mime type
from Real Audio some day.

73 de Jeff
Received on Sat Jun 9 01:26:37 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.