Bug 437427 - debuginfo-install should only use library dependencies
debuginfo-install should only use library dependencies
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-13 20:56 EDT by Bill Nottingham
Modified: 2014-03-16 23:12 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-14 00:22:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-03-13 20:56:34 EDT
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
Comment 1 Seth Vidal 2008-03-14 00:22:21 EDT
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
Comment 2 James Antill 2008-03-14 00:23:31 EDT
 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.
Comment 3 Bill Nottingham 2008-03-14 00:32:18 EDT
(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.

Comment 4 Seth Vidal 2008-03-14 00:32:53 EDT
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?
Comment 5 James Antill 2008-03-14 00:39:03 EDT
(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.
Comment 6 Panu Matilainen 2008-03-14 04:01:33 EDT
> 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.
Comment 7 Bill Nottingham 2008-03-14 09:51:48 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.