rpm-python deficiencies

OK, here's what's what in rpm-python, point by point.

First of all, at least 3 major coding efforts have been attempted over 
the years,
by ewt, msw, and finally me. There are remnants of all 3 abstractions 
hanging
around, none better, but there's more than a bit of bit rot.

Second, aft6er 2 years of begging someone to fix, and various attempts to
bribe and cajole someone into maintaining the bindings, I took over the 
bindings.
This is *INSANE*, having someone who does not code in python maintaining
rpm-python.

Can I do the work? Sure.

Should I do the work? Nah, all I get is headaches, the vast majority of my
rpm development time is wasted (imho) on complicated, arcane, and obscure
"bugs" (sic) from rpm-python.

Pont by p[oi8nt65:

> 1. if you look for hdrobject[rpm.RPMTAG_REQUIREFLAGS] and there is only
> one entry you get back a string object, if there is more than one entry
> you get back a list object, if there is nothing you get back None  -
> it'd be nice if you always got back a list object.

This is maybe 10 minutes work to fix. I cannot make the change because I
do not control the python code that may rely on this behavior. Get me
explicit signoff from the major users in bugzilla, and I can/will get you
a fix.


> 2. I found it mildly annoying since rpm 4.1 that you have to create a ts
> set just to read an rpm header in from a file.

What do you expect? Signature verification is headed for mandatory, that requires
pubkey ring, which requires database, which is attached to a transaction.

This is done this way for simplicity, none of the current rpm-python programs
have any clue about an rpmdb, which now supports concurrent access.

> 3. there should be some better way to simplify/handle the gpg sig
> checking from w/i python:
>  - currently to get all the info on all the signatures that _could_ be
> in an rpm you need to do something like this:
>    string = '%|DSAHEADER?{%{DSAHEADER:pgpsig}}:{%|RSAHEADER?{%{RSAHEADER:pgpsig}}:{%|SIGGPG?{%{SIGGPG:pgpsig}}:{%|SIGPGP?{%{SIGPGP:pgpsig}}:{(none)}|}|}|}|'
>    siginfo = hdr.sprintf(string)
> There are only a handful of people in the world who can read the
> 'string' above and I don't believe I'm one of them.

Yup, pugly as sin. Basically there has never been an attempt in rpm-python to support access
to anything other than 1-D arrays of simple data types in a header. In this case,
one of several binary data type has a RFC-2440 blob inside.

Go look for OpenPGP bindings (they don't exist), and write your own logic to
access one of 4 possible tags, parse out the fingerprint, and do whatever.

Or live with pugly. The h.sprintf() is at least a compact representation, using existing
functionality within rpm intelligently.

The string is exactly what is done by "rpm -qi", so you also have an easy debugging
pathway.

> 4. in the rpm callback it would be nice if erasures had a progress
> callback

Sure it would be nice. The reason that erasure callbacks don't exist is because
they are horrendously misdesigned. The precise reason that no callback is possible
is because the callback needs to present a python object back to python, and that
object does not exist in rpmlib.

Nor is there any way to pass that object to rpmlib, either in the bindings, or in the C API,
for later return to python land on the callback.

And none of the callback crap can be touched because every bleeping rpm-python user
needs to bless the change. Get me explicit consensus in a bugzilla report and I will
rip this callback out so fast your head will spin. Yes, there will be a replacement,
I'm not exactly taking away your progress bars.

> 5. the header object could be 'prettied up' some to be more python-y and
> also to maybe make fairly standard actions easier

WTF is prettied up? The header object is the oldest object in the bindings, there
are teething marks where both ewt and msw learned their python binding craft.

Meanwhile, the header object is already deprecated, and neds to be relegated to
a minor role in using the bindings because of bloat. Headers are plain and
simply the wrong abstraction in the bindings.

Note carefully that the insistence of rpm-python users in continuing to use
headers is *the* impediment to rpm scaling to, say, twice as many packages.

And header tag access is dirt slow, there are 2 bsearch's involved for each tag
access.

> 6. documentation on the python bindings would be nice and ideally
> deleting all the deprecated methods.

Patches cheeerfully accepted. In fact, I have personally asked you for
help several times. There is framework in place, and I will be happy
to document. In fact *all* of the documentation that exists is due to my
efforts. You're welcome.

> 7. I would love to see some standard rpm modules created to wrap around
> the python bindings some to handle fairly standard operations like so we
> all don't end up writing the same code over and over and over again.
> 

Good, somebody else's problem, not mine. ;-)

Don't take my comments personally, please, you just happened to supply the most
detailed complaints, which I can and do appreciate.

73 de Jeff