On 12/22/11 7:56 AM, Jeffrey Johnson wrote:
On Dec 22, 2011, at 7:24 AM, Paul Eggleton wrote:
Hi there,
Whilst working on Poky/OpenEmbedded I found the need to list all of the hard
dependencies of an RPM package within a shell script. Unfortunately --requires
or the REQUIRES tag seem to also include "soft" dependencies (i.e.
"suggests") which is not really what I need. FYI we're using RPM 5.4.0.
Yes: Unlike Debian, Suggests: is an attribute, not a separate tag, that
modifies how a Requires: assertion is to be interpreted. An unsatisfied
Requires: marked with RPMSENSE_MISSINGOK will ignore failed dependencies.
After a little digging I found REQUIREFLAGS, here's an example listing from
our system:
Good (though working with shell processing --qf output is gonna be AWKward ;-)
SHort answer:
Use the --qf output as below but filter with awk to drop any Requires:
that has RPMSENSE_MISSINGOK (1<< 19) set in REQUIREFLAGS.
-------------------- snip --------------------
paul@helios:~/poky/poky/build$
/home/paul/poky/poky/build/tmp/sysroots/i686-linux/usr/bin/rpm --dbpath /var/lib/rpm
--root=/home/paul/poky/poky/build/tmp/work/qemux86-poky-linux/core-image-sato-1.0-r0/rootfs
-q --qf "[%{REQUIRENAME} %{REQUIREFLAGS}\n]" connman-gnome
libglib-2.0-0 12
hicolor-icon-theme 0
libdbus-glib-1-2 12
libgtk-2.0 12
libc6 12
connman-plugin-loopback 524288
connman 524288
python 524288
python-dbus 524288
connman-plugin-dnsproxy 524288
connman-plugin-bluetooth 524288
connman-plugin-udhcp 524288
connman-plugin-ofono 524288
connman-plugin-wifi 524288
connman-plugin-ethernet 524288
connman-plugin-fake 524288
/bin/sh 1280
/bin/sh 4352
rtld(GNU_HASH) 16384
libgtk-x11-2.0.so.0 16384
libdbus-glib-1.so.2 16384
libc.so.6(GLIBC_2.0) 16384
libc.so.6(GLIBC_2.2) 16384
libgdk-x11-2.0.so.0 16384
libgobject-2.0.so.0 16384
libpthread.so.0 16384
libglib-2.0.so.0 16384
libc.so.6 16384
-------------------- snip --------------------
Yes, REQUIREFLAGS here is a bit mask displayed as a decimal integer
which is difficult to filter with a *RE expression.
The most important bits are these (from rpmdb/rpmevr.h)
RPMSENSE_LESS = (1<< 1),
RPMSENSE_GREATER = (1<< 2),
RPMSENSE_EQUAL = (1<< 3),
so a mask of 0x0e needs to be applied to REQUIREFLAGS.
These values are not ideal for filtering via a shell script and I don't know
what the values mean. Mark Hatle pointed me to its fflags modifier which does
appear to translate some of the flags but not for the suggests (e.g.
connman-plugin-* above), here's what it says for the same package:
Here is the Suggests: flags
RPMSENSE_MISSINGOK = (1<< 19), /*!< suggests/enhances hint. */
The other flags are context markers for how/why the dependency was added
and should not be used or relied upon. Note that there are no more available
bits in the int32_t so any additional need is going to require changes
to the existing definitions to recycle (and perhaps redefine) the bit
meanings.
jbj, would it be reasonable to add a context format specific to the dependency
flags? Similar to the fflags so we get a "pretty" print out of the flag values?
(asking within the context of rpm5 development... not the oe-core work)
When I was trying to figure out if one already existed, it looks like it's
fairly simple to add additional rendering formats. (I or someone else could
probably whip up something fairly quickly to render the flags..)
--Mark
-------------------- snip --------------------
paul@helios:~/poky/poky/build$
/home/paul/poky/poky/build/tmp/sysroots/i686-linux/usr/bin/rpm --dbpath /var/lib/rpm
--root=/home/paul/poky/poky/build/tmp/work/qemux86-poky-linux/core-image-sato-1.0-r0/rootfs
-q --qf "[%{REQUIRENAME} %{REQUIREFLAGS:fflags}\n]" connman-gnome
libglib-2.0-0 m
hicolor-icon-theme
libdbus-glib-1-2 m
libgtk-2.0 m
libc6 m
connman-plugin-loopback
connman
python
python-dbus
connman-plugin-dnsproxy
connman-plugin-bluetooth
connman-plugin-udhcp
connman-plugin-ofono
connman-plugin-wifi
connman-plugin-ethernet
connman-plugin-fake
/bin/sh r
/bin/sh r
rtld(GNU_HASH)
libgtk-x11-2.0.so.0
libdbus-glib-1.so.2
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.2)
libgdk-x11-2.0.so.0
libgobject-2.0.so.0
libpthread.so.0
libglib-2.0.so.0
libc.so.6
-------------------- snip --------------------
Any suggestions? Would we need to look at patching RPM to implement better
expansion of the flags? If so, are these flags documented anywhere or is the
source the only reference?
The only bit values that are GUARANTEED have been documented many places. None
of the other bits are GUARANTEED to be supported, and the source is the only
reliable reference because the bit values are RPM version (and fork) dependent.
But if you want some better display format (I've always been fond of the %b
format from ancient *BSD for displaying bit flags), its not to hard to add
a header tag format extension to produce whatever output you wish to see
for REQUIREFLAGS.
Meanwhile -- unless you wish to write your own depsolver -- there is
a --whatneeds generalization of --whatrequires that can be used to
display the hard requirements of package(s): use --dbpath to a datastore
to resolve against if what is installed and registered in /var/lib/rpm/*
isn't relevant to your purposes.
I've forgotten offhand whether (or how) --whatneeds treats RPMSENSE_MISSINGOK.
It wouldn't be too hard to add filtering on RPMSENSE_MISSINGOK and perhaps
a --nosuggests wiring if interested.
(Clearly some of this might be related to our specific configuration of RPM
within Poky/OE, in which case I'll defer to Mark for further elaboration on
that if needed.)
hth
73 de Jeff
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
