Description of problem: NetworkManager has the following requirements: /bin/sh chkconfig 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 iproute libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) libdbus-1.so.3()(64bit) libdbus-glib-1.so.2()(64bit) libdl.so.2()(64bit) libglib-2.0.so.0()(64bit) libgmodule-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgthread-2.0.so.0()(64bit) libhal.so.1()(64bit) libiw.so.29()(64bit) libnl >= 1.0-0.15.pre8.git20071218 libnl.so.1()(64bit) libnm_glib.so.0()(64bit) libnm-util.so.0()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) librt.so.1()(64bit) NetworkManager-glib = 1:0.7.0-0.9.1.svn3440.fc9 openssl ppp >= 2.4.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) wireless-tools >= 1:28-0pre9 wpa_supplicant >= 0.5.7-21 Because debuginfo-install follows package requirements, it will install: openssl-debuginfo wpa_supplicant-debuginfo ppp-debuginfo dhcp-debuginfo bash-debuginfo chkconfig-debuginfo even though those don't actually help you debug NetworkManager itself. Version-Release number of selected component (if applicable): yum-utils-1.1.11-5.fc9
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. http://skvidal.fedorapeople.org/patches/yum-utils-debuginfo-install-libs-only.patch 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
Thoughts: 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 some reason). 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 requires. 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 bit. 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 break 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 break 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.