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? -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
