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): samba-debuginfo-3.0.3-2.pre2 How reproducible: Always 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** libsmbclient.so 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.
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 libraries.
All DSO's need the executable set, that's the current packaging rule. Or change find-debuginfo.sh if you disagree, not hard.
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 missed. 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?