Red Hat Bugzilla – Bug 112389
python: standalone rpm-python bindings, yeah or nay?
Last modified: 2014-01-21 17:48:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
The rpm-python bindings have traditionally linked
to rpm, causing problems because rpm has only a version
One way out of the mess is to make python bindings standalone,
by doing any of
a) swiping code from rpmlib and adding to rpm-python.
b) partial static link against rpm libraries.
c) reimplementing from scratch, with well defined primitives
for handling packages, using native python as much as possible.
d) "freezing" rpm devel forevermore.
and probably other ways.
Personally, I think b) is relatively easy to achieve, which
will buy time to attempt c).
The goal is to uncouple rpm-python development from rpm to
the greatest extent feasible.
I'd like to hear some words re what is desired, please.
I'm curious to know if a branching of rpm into rpm-python and rpm via
suggestion 'b' would cause divergence in results from the rpm cli vs
If you think it won't then I'd be fine with b.
I think C would be neat but it's a long case and difficult and
probably not a good idea for rescue disks and the like.
I'm happy with a or b (with C as a long term goal). I'm slightly more
swayed by adding to rpm-python rather than static linking to be
honest, even if in the short term it means duplication between rpm and
My major concern with a is time constraints leading bitrot, but I
think moving rpm-python forward is a good thing.
Worrying about rpm-python in relation to rescue disks/minimal systems
is a valid, though at this stage I don't know how much of a concern it
is. Certainly thought needs to go in to ensuring a rewrite isn't bloaty.
Hmmm, I swear I replied to this bug.
Divergence is already present, labelCompare vs. rpmds compare
comes instantly to mind. Standalone bindings will not make
matters any worse.
Yes, static linking addresses only dependency issue, and incompatible
a) will not lead to bitrot, bits like header.c primitives are already
well stabilized. Other bindings to read pkgs headers are full of side
effects (like I/O) long complicated code paths that are difficult to
change, and gain a python programmer little other than obscurity.
I suspect that standalone bindings through either a) or c) are
more likely to fit onto rescue disks.
Personally i believe c) is necessary to give python heads full control.
And d) is a real worry, because as sson as rpm is carved into peices,
further development through negotiation with multiple implementation
owners will be impossible.
NEEDINFO so I don't have to stare at this bug any longer ...
Closing due to inactivity. If this issue still occurs with current releases,
please reopen and set the release in which you've encountered the problem.