Bug 112389
| Summary: | python: standalone rpm-python bindings, yeah or nay? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeff Johnson <jbj> |
| Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | nobody+pnasrat, pmatilai |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-04-19 18:40:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. 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 ... 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. |
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.