[Yum-devel] rpm verify in YumInstalledPackages

[seth vidal]

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