On Sat, 26 Jan 2008, seth vidal wrote:
On Sat, 2008-01-26 at 13:18 +0200, Panu Matilainen wrote:
Yup... Where you will get into trouble is checksumming, taking prelinking
into account and that fun, if there are other special cases I don't recall
offhand. Rpmlib knows how to deal with those, and the responsibility of
fetching the on-disk info should be rpmlib's, not each and every API
users'.
I've been thinking about the "verify API" on and off, what I have in mind
at the moment is a (rpmfi) method that'll give you a new rpmfi object,
populated with the on-disk information. With that, all you have to do is
to iterate over the header-fi and ondisk-fi objects and compare the data.
So verifying a package would look somewhat like this:
fi = hdr.fiFromHeader()
dfi = fi.onDisk(patterns=[])
while ... iterate over both rpmfi objects...:
if fi.group != dfi.group:
problems.append("group mismatch")
if fi.mtime != dfi.mtime:
problems.append("mtime mismatch")
...
This would (should ;) work on both C and Python level pretty much "just
like that", without requiring any new data structures and methods to
access the data. rpmlib already knows how to fetch all the ondisk info
naturally, it just throws away the actual data and gives "modified" vs
"not modified" answers. All that's needed is the rpmfiFromDisk()
method (on C-level), should be fairly straightforward to lift the existing
verification code and stuff it into rpmfi...
There you'd have a very simple to use lowlevel "verification API", on top
of which you can then build whatever fancy python verification objects if
you wish.
Thoughts?
The above makes a lot of sense to me. Especially since a number of the
fields in the rpmfi tuple are, umm, not obvious to discern. Doing a
simple comparison would be great. Thanks.
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()
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:
for x in fi:
print fi.FN(), fi.FMode(), os.stat(fi.FN()).st_mode
/usr/bin/telnet -32275 33261
/usr/share/man/man1/telnet.1.gz -32348 33188
Fixed in rpm.org HEAD already, for 4.4.x the only chance is to add casts
in the bindings (will do...)
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... :)
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
