RPM API maintenance
Many applications have attempted to link RPM libraries
over the years.
Useful applications are picked up by linux vendors, creating
an implicit promise of support of applications tied to rpmlib API's.
This creates a pleasant expectation that RPM has an API/ABI that
can be maintained with continuity
The hard truth is this
rpm makes no promises of API/ABI continuity beyond an identical soname
and never has: both the library and the so name are version stamped for years.
The so name (and the API/ABI) can/will change as needed.
The actual reality is that RPM's API/ABI changes very very slowly, and older
applications then need porting, but RPM is blamed for the application breakage.
This blueprint collects reported bugs related to API/ABI "compatibility" and
tracks issues related to the RPM fork (where there are actually 2 "rpm" API/ABI's
with no promise or likelihood of a common API/ABI).
Blueprint information
- Status:
- Not started
- Approver:
- Jeff Johnson
- Priority:
- Low
- Drafter:
- Jeff Johnson
- Direction:
- Approved
- Assignee:
- Jeff Johnson
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Deferred
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
There are several attempts at drop-in "compatibility" through #include
files distributed with "RPM". While there is nothing specifically wrong
with attempting API compatibility using #include's, the mere existence
of the #includes in RPM creates a fuzzy fiction that "compatibility" is
a goal @rpm5.org, and that @rpm5.org is to blame when "compatibility"
doesn't meet expectations. These include files need to be moved out of
code distributed by @rpm5.org.
The major compatibility issues are with apt-rpm, net-snmp (and because
of -debuginfo) gdb/systemtap in @redhat.com distros. The solution for each
of those applications is application specific, but the general forward approach is this:
Remove the -lrpm* linkage to solve the "compatibility" problem forever.
Replace whatever application need with either methods in bindings or
(if its C code) with an application specific data store that rpmlib populates
for each application seeking information from an rpmdb.
