The best way to fix this problem is to have rpm create a store
of file path -> N-V-R.A information so that detached -debuginfo
symbols can be found by gdb when needed. Its easier for rpm
to push specific information when installing -debuginfo packages.
Any other approach
0) linking -lrpm (as done currently)
1) piping to rpm --query
2) dlopen'ing multi-arch libraries as needed
3) removing the dbenv
so that gdb can pull information from an rpmdb forces
gdb to participate in concurrent locking schemes, and will
have failure modes.
Been there, done that, with all of the approaches above:
0) net-snmp currently does -lrpm
1) net-snmp used to run rpm --query
2) Red Carpet tried dlopen with rpm-4.0.2. rather a disaster
3) removing the dbenv opens races for every use of rpm.
The HR-MIB in net-snmp needs to know N-V-R.A and install time,
and that information is now pushed into /var/cache/hrmib at the same
time that a package is registered into an rpmdb. A similar approach with
gdb is better than any other option.
The best way to fix this problem is to have rpm create a store
of file path -> N-V-R.A information so that detached -debuginfo
symbols can be found by gdb when needed. Its easier for rpm
to push specific information when installing -debuginfo packages.
Any other approach
0) linking -lrpm (as done currently)
1) piping to rpm --query
2) dlopen'ing multi-arch libraries as needed
3) removing the dbenv
so that gdb can pull information from an rpmdb forces
gdb to participate in concurrent locking schemes, and will
have failure modes.
Been there, done that, with all of the approaches above:
0) net-snmp currently does -lrpm
1) net-snmp used to run rpm --query
2) Red Carpet tried dlopen with rpm-4.0.2. rather a disaster
3) removing the dbenv opens races for every use of rpm.
The HR-MIB in net-snmp needs to know N-V-R.A and install time,
and that information is now pushed into /var/cache/hrmib at the same
time that a package is registered into an rpmdb. A similar approach with
gdb is better than any other option.