Comment 2 for bug 915287

OK, installed and actually looked at what would be entailed
adding an "abi-dump" target.

The immediate purpose (that I can see) would be to maintain detailed info
regarding rpm library ABI info persistently in, say, an abi-dumps directory
used as the -dump-path argument with abi-compliance-checker.

That can be arranged by adding a new top-level cvs module that is
pulled in with the
    ./devtool checkout
command and a new ABI dump *.abi.tar.gz could be checked in and
maintained as part of an RPM build.

I can drill all that into RPM if that is what you are asking for.

I do point pout that there are almost no programs that link RPM libraries.
E.g.

[jbj@wareham ~]$ readelf -a /usr/lib/librpm-5.4.so | grep SONAME
 0x0000000e (SONAME) Library soname: [librpm-5.4.so]
[jbj@wareham ~]$ rpm -q --whatrequires librpm-5.4.so
perl-URPM-4.38-5-mdv2012.0.i586
abrt-2.0.2-2-mdv2012.0.i586
rpmstats-0.7-4-mdv2012.0.i586
rpm-5.4.4-36-mdv2012.0.i586
rpm-build-5.4.4-36-mdv2012.0.i586
python-rpm-5.4.4-36-mdv2012.0.i586

So basically rpmstats and abrt. I would bundle rpmstats into RPM itself except
    GPLv2 is incompatible with LGPL

abrt is from Fedora, and the usage case is accessing an rpmdb in order
to map a library file name -> package name to find the associated detached debug info.
This COULD and SHOULD be done without linking any rpm libraries, either in a standalone
executable maintained in RPM itself to do the mapping. or (if you simply must) writing
the 100-200 lines of code necessary to do the specific lookup using Berkeley DB
routines, and a simple extraction of the NEVRA information used to create the
prefix of the path where the detached ELF symbols reside.

There's also multiple RPM libraries, each with rather different ABI restrictions.

So there really isn't much of a usage case for maintaining *.abi.tar.gz blobs in @rpm5.org
cvs. But I can/will drill in a "abi-dump" target if you wish.