Re: base objects

On Tue, Mar 23, 2004 at 02:06:50AM -0500, seth vidal wrote:

>  ignoring, for the moment, the rpm-python design let's talk about base
> objects for developing with rpm in python.

Thanks for kicking this off. I should have done this sooner, been caught up in
the detail but I've learnt a lot.

> What are the base objects to start off with? These are the things I find
> myself working with:

> Packages-as-files: opening, checking, etc an actual rpm file

Expanding?  Not sure if it's worth it here.

> Headers: dealing with rpm headers, from files, in database, in yum, etc.

Creating custom header tags?  I'm not sure I'm quite ready for r/w headers but
worth tossing idea over wall.  Querying over http/ftp.

I also think there is package as concept - do users get an rpm as a file vs rpm query from the db.  Should we expect them to?  Does rpm.query() which can take a file or a dbpath/db make sense? 

> Rpm-dbs: querying the rpmdb to extra headers and information

Verification, we have md5 and we're not afraid to use it ;)

> Transaction sets/ts elements: the things I want to perform a 'u,e or i'
> function with.

Ack for all those. 

Dependency Sets (provides/requires) - I think these are a good storage for NEVR
and with comparison enabled if something changes (say per-arch build requires)
then that logic can be done by the object rather than rewriting comparisons.
Again it seems that using srpms for buildrequires is something people want to
do I think that rpmds isa strong candidate to wrapping these changes.

Macros - something I've discussed with Jeff is that if I move to wrapping rpmmodule with python that we could make macros and macro contexts into dicts (rpm.global{}, etc). 

Spec files - still a work in progress but I think people want to be able to parse and possibly kick off builds without exec'ing rpmbuild. Expanded, unexpanded. Creating/auto-generating.

> Are these the base objects/concepts you find yourself dealing with when
> programming for rpm?

Also with groupings trees or sets - is this grouping internally consistent (I
think dependancy set concept works here, as does transaction set).  What do
people do with bunches of rpms, deps, transactions,  build trees, mass source
rebuilds, updates, tree comparison, tree reduction  etc.

Callbacks - maybe a simple one in the python wrapper would be useful out of the
box.

Exceptions - do we want more fine grained exceptions - eg use KeyError for
accessing non-present headers, etc.

> I don't  want to get all bound up in how it currently works, I just want
> to get some ideas on how it would be nice to look, then see if we can
> make it work something like that.

Which I appreciate.  Nice to get a view from above the trenches.  I'll try and
ci _rpmmodule.so changes today to make prototyping easier.

Paul