This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 112389 - python: standalone rpm-python bindings, yeah or nay?
python: standalone rpm-python bindings, yeah or nay?
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-18 15:16 EST by Jeff Johnson
Modified: 2014-01-21 17:48 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-19 14:40:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeff Johnson 2003-12-18 15:16:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030

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 10:38:25 EST
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 11:36:53 EST
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
rpm-python.

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 05:14:38 EST
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 14:40:27 EDT
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.