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
