seth vidal wrote:
On Mon, 2008-01-28 at 11:22 +0200, Panu Matilainen wrote:
The rpmfi tuple (and bunch of others, like in the depsolve callback) is
just #¤%#¤%¤# as tuples can't be extended or changed without breaking
every user... Note that you can access the rpmfi data via methods too, eg
fi = h.fiFromHeader()
for x in fi:
print fi.FN(), fi.FMode(), fi.FFlags()
nod, it's like the odd hdr/matchiterator oddness though.
If you think that's quirky and weird... well I don't disagree ;)
The rpmfi and rpmds "objects" don't have separate iterators on C level
(unlike db, ts etc items) and in this case the brokenness is visible
directly to python too as rpmfi is very thinly wrapped for python.
Not to mention there are other issues like integer signedness conversion
bugs present in the numerical fields, at least FMode() suffers from it
and probably others too:
That explains why I was having some issues getting FMode() to resemble
anything.
Fixed in rpm.org HEAD already, for 4.4.x the only chance is to add casts
in the bindings (will do...)
cool.
Though, if you really want to make me happy by working on some of the
python bindings I have a hankering for rpmbuild. :)
What I've been thinking of, and actually already started at some point but
got side-tracked by variety of other issues is:
The python bindings should be split out of rpm sources to free up the
development. And rpmbuild should be a separate module from the "core"
bindings to avoid dragging librpmbuild.so into things like installer
images needlessly.
The current bindings are so tangled in ugly legacy issues which can't be
changed without breaking half the world, I'm thinking of opting to
developing a new set of bindings, designed from the ground up to be
extensible without breaking and only using public librpm APIs. And
parallel installable to the current ones to make the transition easier.
Take what's sane in the current bindings and scratch + redesign the rest
and once in usable state, mark the in-rpm bindings deprecated (but leave
around for, sigh, legacy support). Implemented in C where necessary and/or
makes sense, otherwise in Python.
Since build bindings don't exist ATM, there are no legacy holdups... so
all that's needed is a design and then just do it ;) yum-devel is not the
best place to discuss that though... :)
What about starting where we talked about before? Give us an python
binding that creates a package file-object and its attributes then we
can start working on what the interface, etc look like a bit at a time?
Having this interface in Python is a good idea. Nevertheless I wonder if it
wouldn't be better to also use the compare code of the rpmlib and just get
back a problem list - as we currently do with the transaction check.
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
