Re: rpm-python list

On Thu, Oct 02, 2003 at 01:31:02AM -0400, seth vidal wrote:
> Hi all,
>  so I made this list - adrian suggested it and it seemed like a
> reasonable thing to do after talking to various folks at red hat.
>
	
	I just didn't have enough to read already.
 
> things maybe worth discussing a bit:
> 
> 1. if you could do whatever with the python bindings to rpm what would
> want to do with them?
>
	same python api (or really damn close) for 
	rpm 4.0/4.1/4.2 and python1.5.2/2.2/2.3
 	(oh, that would be so lovely...)

	bind everything in at least rpmlib (even if it's
	ugly), then a nice pretty layer on top of it
	that does all nice pythonic stuff (aka, a
	_rpm and an rpm module, as per other similar modules)

	read/write/change/query macros directly

	bindings to anything the commandline can
	do (aka, -V, for an obvious example)
	
	better conflict info in the new debsolver
	callback

	ablility to generates headerlike objects
	(whatever that might be) from non header
	data (aka, xml, etc...)

	 improved support for creating/populating
	"rpmdb" like datastores (sorta kind of works
	now, forget what problems exactly...)

> 2. what problems do you current have using the bindings
>
	mostly lack of bindings for a few things here
	and there
		
	I've got various minor gripes and complaints
	about the api, most of which I've forgotten	

 
> 3. what cool things are people working on doing with them
> 
	up2date, various deprecated rpm graphing hacks,
	misc package inspection tools, sundry rpm
	hacks of wildly varying utility


> 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.
>
	I've apparently block that one out of my memory, but yeah,
that would be nice.
 
> 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.
> 
	yeah, agreed. would be nice to have an object that
represents a "file that happens to be an rpm' and/or ditto
for headers. with all the open/close/read/save/etc/etc methods

> 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.
> 
	well, for the stuff I care about, SIGGPG is
all I need. But sure, the rest wouldnt hurt (aside
from complexity)

> 4. in the rpm callback it would be nice if erasures had a progress
> callback
> 
	I'd flag callbacks in general as "needing some more thought"

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

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

> 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.
>
	yeah, see above
 

Adrian