On Apr 19, 2008, at 11:58 AM, devzero2000 wrote:

>   I don't know of any other implementation that alrerady supports as
>     wide a variety of existing platfom  xattr's/acl's, is as simple  
> to use as tar,
>     and can be extended to handle new per-file metadata rather easily.
>
> Maybe not directly connected, i am't sure,  but could be  
> interesting to look at libferris and see if it can offer any  
> interesting idea for RPM, or for a package management system in  
> general.
>
> http://www.linuxjournal.com/article/8901
>
> It was some time which I am thinking about it but i haven't able  
> until now to see for what measure can be useful (perhaps rollback   
> without saving rpm e.g a journal metadata or the like).
>
> It could be of starting point for a future evolution of the RPM.
>

Having a "richer" (and simpler) retrieval through a file system like  
interface
like libferris is doing needs to be attempted with RPM package metadata.

Using FUSE as the means to present package metadata seems (to me) to
be easier than attempting a more traditional approach for application  
support
through bindings etc. The issue is the cost of maintaining code and  
coordinating
fixes. E.g. rpm-python development has stagnated for years basically  
because
applications like yum/anaconda _MUST_ have exactly the same interface as
they always have had. There are similar issues with URPM through rpm- 
perl,
and I don't expect any other language bindings to be different. That  
hardest
issue is that all the bindings are different, different methods,  
different needs, different
releases, different developers, so carrying all the bindings within  
rpm is rather
cumbersome. OTOH, bindings within rpm leads to incompatiblities being  
addressed
way sooner than if the bindings were seperate projects.

Meanwhile libferris is in C++, rpm is in C. Not good.

The most significant problem with using libferris (or external file  
system library)
is that rpm itself does not need a "rich" file system presentation.  
Applications
that use rpm packages would benefit from a simpler file system  
presentation of package
metadata, and so the applications, not rpm, would have to choose  
libferris.

If applications wanted to use libferris, an rpmdb module could likely be
developed. Other alternatives to libferris are exporting XML/YAML  
metadata, or just using
an existing file system to present the basic information that package  
applications
desire (see how net-snmp can use /var/cache/hrmbib/* data instead of  
linking an rpmdb)
are so far adequate means to deliver rpm metadata to applications.

Increasingly I expect that applications will just read *.rpm metadata  
directly without
rpmlib involvement (that's the SuSE sat-solver model), or devise  
means to
map their own data into something that can be registered as a rpm  
package (that's
LSB's Berlin API approach, doomed because it depends on API adoption,  
and API
methods  are too hard to support. see reasoning in previous paragraph).

And then there is D-BUS message passing ala PckageKit, everone gotta  
do their own thing,
but that has a rather different need, interfacing a desktop and  
simplifying software
installation tasks using a GUI. Note no file system at all.

But if there's interest, it likely would not be hard to export rpmdb  
metadata in a XML
format that could be used by  libferris immediately. A libferris  
module for an
rpmdb could likely be attempted, handling Header tags is just detail  
work,
land ibferris already has a db4 module (but likely uses a very  
different schema than what
is in a rpmdb).

hth

73 de Jeff