[Yum-devel] rpm verify in YumInstalledPackages

Panu Matilainen pmatilai at laiskiainen.org
Wed Jan 30 07:08:36 UTC 2008


On Mon, 28 Jan 2008, 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.

Not quite. The hdr/mi goes like

mi = ts.dbMatch(...)
for h in mi:
     print h['name']

if it were like the rpmfi, it'd be

mi = ts.dbMatch(...)
for h in mi:
     print mi.Name()

or something like that :) In any case, it's a somewhat ugly inconsistency 
in the API, both in C and Python.

>> 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.

Yup...

>
>> 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?

I think a more approachable starting point would be adding bindings to 
just drive a spec build from python :)

 	- Panu -



More information about the Yum-devel mailing list