Bug 120992 - find-debuginfo.sh doesn't find all shared libraries (the ones that have no 'x' bit set)
Summary: find-debuginfo.sh doesn't find all shared libraries (the ones that have no 'x...
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-15 22:12 UTC by George Karabin
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-16 01:35:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description George Karabin 2004-04-15 22:12:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
.debug files should be present corresponding to the libsmbclient.so*
files installed by samba-common, but they aren't. Oddly enough, .debug
files are present for other 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
rpm -ql samba-debuginfo|grep .so.debug

Actual Results:  A bunch of .debug files for libraries **not
including** libsmbclient.so

Expected Results:  A bunch of .debug files for libraries **including**

Additional info:

This would be handy for diagnosing some problems with gnome-vfs smb
browsing that I'm seeing on my network. I'll probably just rebuild
libsmbclient at some point for debug, but it'd be more handy if I
didn't have to. Not really helpful to debugging this, but motivation
for why bother fixing this for such an obscure library.

Comment 1 George Karabin 2004-04-16 00:07:14 UTC
This appears to be a more generic problem in the rpm-build package.
find-debuginfo.sh only looks for debug information in files that are
executable, and libsmbclient.so is not executable. The relevant
fragment is:

    for f in `find $RPM_BUILD_ROOT -path "${debugdir}" -prune -o -type
f \( -perm -0100 -or -perm -0010 -or -perm -0001 \) -exec file {} \;

Most shared libraries installed by Fedora Core have the executable bit
set, so this is OK as a heuristic, but it's not very accurate since
many others (including libsmbclient.so,  some dri modules in xorg-x11,
libc.so in glibc-devel, etc...) do not. AFAIK, ldd doesn't care about
the bit's status one way or the other.

I'm guessing that the permissions filter is purely a speed
optimization, and that there are no other side effects. Removing it
would seem OK if that assumption holds. If the speed does matter, a
reasonable compromise might be to only check permissions on files that
are outside the known system library directories (/lib, /usr/lib,
/usr/X11R6/lib, ...). That seems hard to maintain, and will still miss

Comment 2 Jeff Johnson 2004-04-16 01:35:53 UTC
All DSO's need the executable set, that's the current packaging rule.

Or change find-debuginfo.sh if you disagree, not hard.

Comment 3 George Karabin 2004-04-16 03:00:55 UTC
Thanks - I wasn't aware of the rule. It complicates fixing the problem - I could use some 
suggestions for how to proceed. I'm interested in getting the debug symbols for all of the 
DSOs in Fedora into the release, including the ones that don't have the execute bit set 
fixed in Fedora. Tweaking find-debug.sh on my box doesn't help anyone but me - I'll 
submit a patch if you'd accept it, but I don't think you'd apply it (not sure, you're last 
sentence was a little terse, but I'll ask anyway).

So if the policy is set in stone, can you suggest the best way for me to go about improving 
the situation? I can think of 3 options:

1) I could start submitting patches to redhat bugzilla for spec files to packages that have 
this sort of problem. 

2)  I could submit the patches upstream so that the 'make install' rules always follow the 
+x convention, and no spec files need tweaking.

3) I could post to fedora-devel or someplace more appropriate if you think this needs 
broader discussion, i.e., if a requirement for setting the packaging rule convention was 

In a vacuum, I think option #1 makes sense. It requires a bit more maintenance, but #2 is 
probably impossible to push without exceptions since there's no standard to refer to when 
trying to get upstream maintainers to decide the right option (in fact, AFAICT, Debian has 
the opposite policy if the checks that 'lintian' does are authortative). #3 only makes sense 
if you know something I don't know.

Also, would it help if I asked the maintainers of the fedora.us QAChecklist to add this 
packaging rule to their packaging QA page (http://www.fedora.us/wiki/QAChecklist), so 
that packages that migrate from fedora.us to Fedora Core already follow the rule?

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