From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 Description of problem: Absent a public build tree (and perhaps even in concert with one), I propose the following: I believe that providing debugging symbols for binary packages would result in better bug reports from users, including more patches! I propose that packages are built with -g (since this works with -O when using gcc) and the stripped symbols are placed in separate RPM packages (foo-debug?). This could be done automatically by rpm-build when it strips the binaries, with a separate package created for each sub-package that contained object code (i.e., foo-debug, libfoo-debug, etc.). Ideally, one would provide an "unstrip" facility (fenris has appropriated the name "dress") in binutils, so that the user could recreate the unstripped executable or library, and use their favorite debugger (gdb, ups, etc.). Before replying "but you need the build tree anyway," let me add that (1) rpm -bp and perhaps a "configure" is cheap, and (2) several debuggers have integrated interpreters that handle the little stuff. It *is* necessary to make sure that something reasonable is done with the file paths in the debugging info, though. [I'd suggest unstripping allow relocation on the file paths.] I would not expect RedHat to ship these packages to customers (except perhaps on Advanced Server), as the size cost is likely to be prohibitive. But the packages could readily be made available on RHN and the usual mirrors, as users only need the packages that they intend to debug. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. Find bug. 2. Get SRPM, hack spec file, wait minutes to hours (XFree86, gcc) to rebuild unstripped. Worry that build environment is different. 3. Localize bug and create (often trivial and obvious) patch. Actual Results: User doesn't bother to find and fix the bug. Expected Results: Lots of small patches fixing thinkos. Additional info:
This is mostly functional in rpm-4.1, completely functional in rpm-4.2-0.10 packages.