[Yum-devel] rpm verify in YumInstalledPackages

[Florian Festi]

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