Red Hat Bugzilla – Bug 437427
debuginfo-install should only use library dependencies
Last modified: 2014-03-16 23:12:52 EDT
Description of problem:
NetworkManager has the following requirements:
config(NetworkManager) = 1:0.7.0-0.9.1.svn3440.fc9
dbus >= 1.1
dbus-glib >= 0.73-6
dhclient >= 3.0.2-12
hal >= 0.5.0
libnl >= 1.0-0.15.pre8.git20071218
NetworkManager-glib = 1:0.7.0-0.9.1.svn3440.fc9
ppp >= 2.4.4
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
wireless-tools >= 1:28-0pre9
wpa_supplicant >= 0.5.7-21
Because debuginfo-install follows package requirements, it will install:
even though those don't actually help you debug NetworkManager itself.
Version-Release number of selected component (if applicable):
okay so it's a bit hacky but:
- if the dependency off of the package contains '.so' then it will install the
debuginfo package for that dep.
it does do what you seem to want it to do above and it makes sense as the
default to me.
I'm going to check it in upstream and it'll be out in the next yum-utils release
1. What happens on any deps. things have for stuff they dlopen.
2. What about things that use helpers that are in a separate package (Ie.
/usr/sbin/NetworkManagerDispatcher is moved to NetworkManager-Dispatched, for
3. What happens for any packages that turn off autodeps. and have explicit requires.
4. What do we do about versioned requires (not that many C libraries have symbol
versioning, including Base stuff like glib -- and all of the above, apparently).
For instance, atm. debuginfo-install should basically get the dep.
NetworkManager-glib-debuginfo = 1:0.7.0-0.9.1.svn3440.fc9 ... after the "only
shared libs." change it'll just be "any version of
NetworkManager-glib-debuginfo" which == the most recent.
(In reply to comment #2)
> 1. What happens on any deps. things have for stuff they dlopen.
Wouldn't get pulled in, but I think that's probably the minority (I suspect hte
majority of those packages don't have Requires: for them.)
> 2. What about things that use helpers that are in a separate package (Ie.
> /usr/sbin/NetworkManagerDispatcher is moved to NetworkManager-Dispatched, for
> some reason).
Not seeing why this would fail now and not fail then.
> 3. What happens for any packages that turn off autodeps. and have explicit
Don't do that! I mean, turning off autodeps and explicitly adding Requires:
<some library> is just wrong.
1. we need to have a way of having rpm auto-tag things which are libraries
2. we need to have a way of having rpm auto-tag things which are libraries
3. that's just wrong and people should expect things like debuginfo-install to
be hurky in that case.
4. we need to have a way of having rpm auto-tag things which are libraries.
See a trend?
(In reply to comment #3)
> Wouldn't get pulled in, but I think that's probably the minority (I suspect hte
> majority of those packages don't have Requires: for them.)
It should be the minority, and you might be right about the requires ... I
don't have stats. either way.
> Not seeing why this would fail now and not fail then.
Because they'd have a dep. on the pkg providing the helper.
> Don't do that!
If we ban this in Fedora that's fine, but I didn't think we did.
> we need to have a way of having rpm auto-tag things which are libraries
The information is mostly there already, just need to dig for the information a
1) If there are automatically added provides, it is contains a library of some
sort (whether it's ELF or perl library is another question):
ts = rpm.ts()
mi = ts.dbMatch()
for h in mi:
ds = h.dsFromHeader(rpm.RPMTAG_PROVIDES)
for d in ds:
if d.Flags() & rpm.RPMSENSE_FIND_PROVIDES:
# it's a lib of some sort
The other place where you can look is the file classification info, something like:
fi = h.fiFromHeader()
for f in fi:
if fi.FClass().find("shared object") != -1:
# it's an elf lib, most likely
Of course looking at dependency/provide names and looking for "*.so*" will
pretty much do the same thing in practise.
One possible extra heuristics that should help catching some of the dlopen and
manual dependency cases:
1) if the dependency is a *.so dependency (or RPMSENSE_FIND_REQUIRES dep),
install debuginfo (this is what patch from comment #1 does)
2) otherwise see if the package providing the dependency has *.so provides (or
RPMSENSE_FIND_PROVIDES provides), if yes then install debuginfo for it
2) Would help bringing in things where manual dependency is used for a library
for whatever reason. Of course there would be false positives, like openssl in
the above case, but no amount of rpm tagging will help determining how a piece
of software *uses* it's dependencies.
(In reply to comment #5)
> > Not seeing why this would fail now and not fail then.
> Because they'd have a dep. on the pkg providing the helper.
Sure, but in that case you're debugging *that other package*, not
NetworkManager. This would be the same as installing bash-debuginfo now because
NM's %post script calls bash - it's not really the case you want to optimize for.