On Fri, Apr 4, 2008 at 10:54 PM, Dave Peterson <dave_peterson@xxxxxxxxxx> wrote:
Hi,
I have a little C++ program I wrote that uses RPM library
calls to extract dependency info from RPM files, and then
does some analysis on the extracted info. As input, the
program takes the entire set of RPMs in the CentOS 5
distro. Looking at the output, I notice that there are a
number of capabilities required by packages in the distro
but not shown as being provided by any package in the
distro. Almost all of these are full pathnames (for
instance "/bin/sh" and "/bin/gzip"). The remaining few
are strings that look like they specify things provided
by the RPM library itself (such as
"rpmlib(CompressedFileNames)" and
"rpmlib(PartialHardlinkSets)").
OK.
Based on these observations, I am guessing that the
following conventions probably apply to strings extracted
from RPM headers that represent required capabilities:
1. Any capability string that looks like an absolute
pathname should be treated as one. In addition
to packages that explicitly list such a
capability as being provided, any package whose
set of included files contains a matching
absolute pathname should be treated as providing
that capability.
Yes. Any capability that starts with a '/' is a file dependency.
2. Any capability string that looks like
"rpmlib(...)" should be assumed to refer to
something provided by the RPM library itself.
Yes. Any capability enclosed by rpmlib(...) is provided by the rpm implementation.
Is this correct? If so, I have a couple of questions:
- The RPM package that provides the RPM library
itself (rpm-4.4.2-37.el5.i386.rpm for CentOS 5)
doesn't list capabilities such as
"rpmlib(CompressedFileNames)". Is there any way,
just by using RPM library calls to get info from
the RPM package, to determine whether it provides
things such as "rpmlib(CompressedFileNames)"? If
not, how do I use RPM library calls to ask the RPM
library on an installed system which capabilities
of this type it provides?
Yes. Leme check ...
In rpm-4.4.2 the API to retrieve rpmlib(...) dependencies is:
/** \ingroup rpmtrans
* Return copy of rpmlib internal provides.
* @retval provNames address of array of rpmlib internal provide names
* @retval provFlags address of array of rpmlib internal provide flags
* @retval provVersions address of array of rpmlib internal provide versions
* @return no. of entries
*/
/*@unused@*/
int rpmGetRpmlibProvides(/*@null@*/ /*@out@*/ const char *** provNames,
/*@null@*/ /*@out@*/ int ** provFlags,
/*@null@*/ /*@out@*/ const char *** provVersions)
/*@modifies *provNames, *provFlags, *provVersions @*/;
There's a different API in more recent rpm that returns a populated
dependency set instead of raw arrays.
But if you're writing an application that uses rpm libraries, you can also just
ignore all rpmlib(...) dependencies. The dependencies are meant for rpmlib,
not for applications.
- Are there any kinds of strings other than absolute
pathnames and things like
"rpmlib(CompressedFileNames)" that an RPM header
may list as required but must be treated as special
cases?
The general
Requires: foo(bar)
is an attempt at namespaces for dependencies. So the general answer is
that there are an infinite number of foo(bar) constructs, each of which
should be handled (in some ideal sense) by handing off to a namespace
handler.
In practice, "foo(bar)" is just a string that can be matched against other strings,
noone really groks namespace for dependencies (although its kinda obvious that
all dependencies that start with '/' are file dependencies, just another name space).
Running
rpm -qa --qf '[%{requirename|\n]' | grep '(' | sort -u
will give you a pretty clear idea of what namespace dependency strings are currently in
use on your distro.
hth
73 de Jeff
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
