for the 2) questions the answer is yes. rpmlib(xxxxx) and /bin/sh are special requirement
to rpm library itself and for the bourne shell script to run the installation scripts (e.g. %pre %post and so), respectively . For example, rpmlib(VersionedDependencies) >= 3.0.3-1 in facts is a dependency from rpm itselfs: the package in questions hold dependecies or prerequisites that have versions associated with them: the spec file have probabily something like Requires : foo >= 1.1. In fact it is possible in rpm to define Versioned Dependency from rpm >= 3.0.3. The rpm tags RPMTAG_REQUIRENAME and RPMTAG_REQUIREVERSIONS should be list this requisites. For the second point you ask
it is possibile to have also the requisite "lsb" with version "1.3" or so, iirc - i have not see it anyway: it mean that the package conforms to the Linux Standard Base RPM format (which means no requirements or provides are defined other from lsb-xxx modules itself and that the payload are compressed with gzip at compression level 9, more or less - not exactly a good thing or useful IMHO). In fact in rpm 5 (rpm5.org, unlikely you use) in the rpm build (rpmbuild command) it is possible to pass the popt option --lsb that means exactly --noautorequires --noautoprovides. From RPM 4.4.4 exist also other depency as libtool(....) depencies , but, again, it is unlikely you see ever in CentoOS - but in PLD Linux, i have read, Yes for example
hth
On Sat, Apr 5, 2008 at 4:54 AM, 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)").
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.
2. Any capability string that looks like
"rpmlib(...)" should be assumed to refer to
something provided by the RPM library itself.
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?
- 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?
Thanks in advance for any help you may be able to provide.
Dave
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
