This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Hello Justin,

it seems to be fixed in current version of ABRT

$ repoquery --requires abrt
...
librpm.so.1()(64bit)
...

Hi Karel,

Unfortunately, that is also shown on the RHEL 6 system this error occurred on.
:(

  $ repoquery --requires abrt | grep rpm
  librpm.so.1()(64bit)
  librpmio.so.1()(64bit)
  $

Running the above reqoquery against every package installed on the system also
didn't reveal anything:

  $ for i in `rpm -qa`; do echo $i | tee -a /tmp/repoquery.output; repoquery
--requires ${i} | grep rpm | tee -a /tmp/repoquery.output; echo | tee -a
/tmp/repoquery.output; done

Grepping the output of the above shows several mentions of librpm.so.1, but
none for .0.

Any ideas?

Getting creative and scanning everything on the system that even looks executable didn't help either:

  $ for i in `sudo find / -type f -executable -xdev`; do echo $i | tee -a /tmp/repoquery.output; sudo ldd ${i} | grep librpm.so | tee -a /tmp/repoquery.output; echo | tee -a /tmp/repoquery.output; done

Still nothing shows up that refers to librpm.so.0.

:/

Running "strings" against every file on the file system showed an interesting possibility:

  $ for i in `sudo find / -xdev -type f`; do echo $i | tee -a /tmp/repoquery.output; sudo strings ${i} | grep librpm.so | tee -a /tmp/repoquery.output; echo | tee -a /tmp/repoquery.output; done

In the output it lists:

  /usr/bin/gdb
  librpm.so.0

gdb in this case is from:

  $ rpm -qf /usr/bin/gdb
  gdb-7.0.1-23.el6.x86_64
  $

Running ldd against gdb didn't reveal anything useful:

  $ ldd /usr/bin/gdb
	linux-vdso.so.1 =>  (0x00007fff1917b000)
	libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003169e00000)
	libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003b0da00000)
	libz.so.1 => /lib64/libz.so.1 (0x000000385bc00000)
	libm.so.6 => /lib64/libm.so.6 (0x000000385b400000)
	libdl.so.2 => /lib64/libdl.so.2 (0x000000385ac00000)
	libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x000000316d200000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x000000385d000000)
	libc.so.6 => /lib64/libc.so.6 (0x000000385a800000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x000000385d800000)
	/lib64/ld-linux-x86-64.so.2 (0x000000385a000000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x000000385b000000)
	libutil.so.1 => /lib64/libutil.so.1 (0x0000003169600000)
  $

So this could just be a junk match.  However, I'm not so sure.

Is there any chance ABRT runs gdb in some fashion to determine the debugging symbols needed for a backtrace, or similar?

Good catch! Thank you for the investigation.
Yes, ABRT calls gdb.

I checked the GDB changelog and this bug has been fixed, but the fix has been ported to RHEL-6 later.

* Sat Jan 16 2010 Jan Kratochvil <jan.kratochvil> - 7.0.50.20100116-1.f13
...
- Update rpm.org#76 workaround for rpm-4.8 using librpm.so.1.

Current RHEL-6 version is gdb-7.1-21.el6.x86_64, ./configure is called with option "--with-rpm=librpm.so.1".

Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.