Re: rpm-python list

Tim Powers <[email protected]> Thu, 2 Oct 2003 08:04:14 -0400
Newsgroups gmane.linux.redhat.rpm.python
Message-ID <[email protected]>
On Thursday, October 2, 2003, at 01:31 AM, seth vidal wrote:
> 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.
>
> 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.
>
> 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.
>
> 4. in the rpm callback it would be nice if erasures had a progress
> callback
>
> 5. the header object could be 'prettied up' some to be more python-y  
> and
> also to maybe make fairly standard actions easier
>
> 6. documentation on the python bindings would be nice and ideally
> deleting all the deprecated methods.
>
> 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.

The list above mirrors my gripes, although I hadn't really thought  
about #4.

#1 is especially good at taking clean code out to pasture.

Typically my uses of the python bindings are for utility scripts, from  
composing trees to sanity testing on individual packages and package  
sets.  Recently it has also been to verify signed packages are signed  
with the correct sig for specific milestones (which I too have found to  
be non-trivial with the current bindings).


Tim