Bug 112389 - python: standalone rpm-python bindings, yeah or nay?
Summary: python: standalone rpm-python bindings, yeah or nay?
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: 1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-18 20:16 UTC by Jeff Johnson
Modified: 2014-01-21 22:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-19 18:40:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jeff Johnson 2003-12-18 20:16:16 UTC
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
specific ABI.

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.

Comment 1 Seth Vidal 2004-01-23 15:38:25 UTC
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
python scripts.

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.

Comment 2 Paul Nasrat 2004-01-23 16:36:53 UTC
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.

Comment 3 Jeff Johnson 2004-01-26 10:14:38 UTC
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
ABI changes.

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 ...

Comment 4 Jeremy Katz 2005-04-19 18:40:27 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.