pathnames, etc. as required capabilities

[Dave Peterson]

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

[devzero2000]

As far i know,

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

Post by Dave Peterson
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
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.
- 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
https://www.redhat.com/mailman/listinfo/rpm-list

[Jeff Johnson]

Post by Dave Peterson
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.

Post by Dave Peterson
Based on these observations, I am guessing that the
following conventions probably apply to strings extracted
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.

Post by Dave Peterson
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.

Post by Dave Peterson
- 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.

Post by Dave Peterson
- 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

[Jeff Johnson]

Post by Dave Peterson
- 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?

Sorry, I did not answer you question precisely.

The rpmlib(...) dependencies are part of the rpm implementation, not the rpm
package.

You can find out what capabilities are provided by the implementation using
--showrc,
which will also display the "features" that are being tracked with
rpmlib(...) dependencies.

73 de Jeff

[Dave Peterson]

Post by Jeff Johnson
Sorry, I did not answer you question precisely.
The rpmlib(...) dependencies are part of the rpm
implementation, not the rpm package.
You can find out what capabilities are provided by
the implementation using --showrc, which will also
display the "features" that are being tracked with
rpmlib(...) dependencies.
73 de Jeff

Ok, thanks for the info. I'm curious, is it possible
that a package may fail to install because it depends
on some feature of the RPM library represented by a
rpmlib(...) capability?