Description of problem: hardlinks across multiple binary packages do not work. Verify this behavior on the new /usr/lib/rpm/find-debuginfo.sh. Version-Release number of selected component (if applicable): rpm-build-4.8.1-2.fc13.x86_64 openoffice.org-debuginfo-3.2.0-12.31.fc13.x86_64 How reproducible: Always. Steps to Reproduce: 1. Crash OpenOffice.org. 2. gdb -c ./core.31254 Actual results: Missing separate debuginfo for the main executable file Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/d4/008a98dcd242e9d39ec7aebf97a11155293987 Expected results: Main executable is found. Additional info: broffice.org-brand.rpm and openoffice.org-brand.rpm shared the same build-id binary. $ readlink /usr/lib/debug/.build-id/d4/008a98dcd242e9d39ec7aebf97a11155293987 ../../../../lib64/broffice.org3/program/soffice.bin $ repoquery -qf /usr/lib64/broffice.org3/program/soffice.bin broffice.org-brand-1:3.2.0-12.31.fc13.x86_64 $ eu-readelf -n /usr/lib64/openoffice.org3/program/soffice.bin Build ID: d4008a98dcd242e9d39ec7aebf97a11155293987 $ repoquery -qf /usr/lib64/openoffice.org3/program/soffice.bin openoffice.org-brand-1:3.2.0-12.31.fc13.x86_64 /usr/lib/rpm/find-debuginfo.sh should probably create /usr/lib/debug/.build-id/... as regular files and symlink /usr/lib/debug/usr/bin/... to them or so. This should be in fact a "rpm" Component Bug.
The benefit of the current direction of symlink is that you can resolve the .build-id link to see the proper human-readable file name. libdwfl does this so e.g. eu-unstrip -n lists meaningful file names instead of just build IDs. What's the practical failure caused by the duplication? This will be moot in the mythical grand debuginfo revamp as I imagine it, so I wonder if it could just be punted until then.
(In reply to comment #1) > What's the practical failure caused by the duplication? If you have openoffice.org-brand*fc13.rpm installed and you do not have broffice.org-brand*fc13.rpm installed (the most usual case) you cannot find the binary according to d4008a98dcd242e9d39ec7aebf97a11155293987. The "gdb -c ./core.31254" currently does not work for F13 OOo.org. (To find the main executable and properly backtrace it.) It works for any other binary. One can for example forbid equal-build binaries in different binary rpms or so.
Created attachment 479652 [details] /usr/lib/rpm/find-debuginfo.sh fix for all instances of a build-id. Output for hardlinks: -rwxr-x 3 4104 /usr/bin/a -rwxr-x 3 4104 /usr/bin/b -rwxr-x 3 4104 /usr/bin/c drwxr-x 2 0 /usr/lib/debug drwxr-x 2 0 /usr/lib/debug/.build-id drwxr-x 2 0 /usr/lib/debug/.build-id/8f lrwxrwx 1 17 /usr/lib/debug/.build-id/8f/a6 -> ../../../../bin/c lrwxrwx 1 17 /usr/lib/debug/.build-id/8f/a6.1 -> ../../../../bin/a lrwxrwx 1 21 /usr/lib/debug/.build-id/8f/a6.1.debug -> ../../usr/bin/a.debug lrwxrwx 1 17 /usr/lib/debug/.build-id/8f/a6.2 -> ../../../../bin/b lrwxrwx 1 21 /usr/lib/debug/.build-id/8f/a6.2.debug -> ../../usr/bin/b.debug lrwxrwx 1 21 /usr/lib/debug/.build-id/8f/a6.debug -> ../../usr/bin/c.debug drwxr-x 2 0 /usr/lib/debug/usr drwxr-x 2 0 /usr/lib/debug/usr/bin -r--r-- 3 14112 /usr/lib/debug/usr/bin/a.debug -r--r-- 3 14112 /usr/lib/debug/usr/bin/b.debug -r--r-- 3 14112 /usr/lib/debug/usr/bin/c.debug drwxr-x 2 0 /usr/src/debug/multidebug-1.0 If it gets approved I will patch GDB to find the first such symlink with existing target file. It should affect I hope only OOo/LO which get often updates so a GDB workaround for existing debuginfos by some brute force file search may not be required.
Created attachment 479654 [details] Test .spec file.
In GDB since: 7.2.90.20110429-37.fc15 - Search also for .<seqno> files in /usr/lib/debug/.build-id (BZ 641377). Requesting the Comment 3 patch for F-16 rpmbuild.
ping
Duh, sorry, I'd forgotten all about this. In rawhide now as of rpm-4.9.0-8.fc16.