Re: Re: rpm-python legacy issues

On Wed, Oct 15, 2003 at 12:16:32PM -0400, Jeff Johnson wrote:
> Anyone I haven't picked on yet? ;-)
> 
> >	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...)
> 
> 
> As long as I am not permitted to release rpm errata, I
> cannot release a common API in rpm-python.
> 
> OTOH, there is absolutely nothing stopping you from
> grabbing rpm-python code and carrying your own
> bindings where ever you and up2date need to go.
> >	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)
> 
> And this is the Dumpty (or kitchen-sink) approach to rpm-python,
> just give me everything I will ever need -- good/bad/ugly -- so
> that I can program in python, not C.
> 
> Not gonna work imho.
>
	I disagree. It's about the only scaleable
way to do bindings to complicated C api's that I've
seen. Hand crafted bindings are fine, but are hard
to be complete, and to maintain over shifting apis. 

	There are undoubtedly things that might
be better done as a C level python (something
that might require creating a new type for
example), but in general, I think it's better
handled at a high level. 
 
> 
> >        read/write/change/query macros directly
> 
> Already in rpm-python is my binding craft teething marks
> to treat macro configuration as a python dictionary, calling
> addMacro/delMacro as side effects of adding/deleting from
> a dictionary like object.
> 
> The idea is perfectly sound, probably exactly what you want.
> I abandoned the effort when I discoverer PEP 253/254, and
> realized that sub-typing is not at all the same thing as
> sub-classing in Python. Ooooh, wisdom teeth, sharp too!
> 
	does that mean this works, or what? I'm not
following the metaphors. 


> >	better conflict info in the new debsolver
> >	callback
> 
> Not gonna happen as requested. conflicts are not detected
> using ts.check(), but rather during ts.run().
> 
> Sure, an explict method and better doco and ... is preferable.
> If up to me, I'd eliminate ts.check() and ts.order() methods
> entirely, substituting instead incremental dependency checking
> and ordering with all information available immediately
> after ts.addInstallElement().

	Sounds like the depsolve callback, which is
what I'm talking about, not ts.run. It doesn't present conflict
info with enough context to be useful as best
I can tell. And I'm talking about package conflicts,
not file conflicts (though, file conflicts 
would be cool as well) 

 
> 
> >	ablility to generates headerlike objects
> >	(whatever that might be) from non header
> >	data (aka, xml, etc...)
> 
> So you want to write your own headers, do you?
> 
	Yes. Or...

> I have deliberately made headers readonly objects because
>     a) creating immutable header regions is very, very subtle.
>     Any screw up that gets deployed in the field will be a
>     major support headache for all rpm users.
>     b) headers need to die, they are the wrong abstraction imho.
> 
	I dont really care if they are headers or a
"headerlike object". As long as it has the same info and
there are easy ways to get that object created and populated
from a package or some sane data blob thats smaller than
an entire package. At the moment, that means a header.
	And/or I can convert to a header _or_ I no
longer need headers to create a transaction set. 

	Or I could rewrite everything to not use 
transactions in my dep solver (current style or
new style "depsolve callback", both currently
require headers to create a transaction to 
solve deps).

> But I'll be happy to add methods to create headers, not hard, but
> the consequences -- screw ups -- will of necessity not be my rpm problem
> anymore.
>
	sans a common headerlike datastruct, creating
headers is required. I have to have them to create
and run transactions. As mentioned above, a
replacement object that is equilivent is fine.
But not having either isnt workable. 
 
> >	 improved support for creating/populating
> >	"rpmdb" like datastores (sorta kind of works
> >	now, forget what problems exactly...)
> 
> 
> Yes, there is a need to expose the dbi layer within rpmdb.
> 
> This has not been done becuase:
>     a) no rpm-python is prepared for the statefulness associated with
>     Berkeley DB concurrent access.
>     b) the interest so far has been in KISS collections of header blobs,
>     and defining XML for header content, rather than more intelligent
>     access to collections of headers.

	I have 0 interest in XML myself. I want access to get to
"objects representing all the info in an rpm" (aka, headers
atm). If thats though a db, cool. At the moment, it's though
a Big Pile-O-Headers cause thats the only workable approach
(well, I could create and destroy hdlists, but thats a 
marginal improvement at best). If theres magic to
marshall headerlike data as XML and store it in blobs.
Fine. Cool. Whatever. Dont care. I need the info. At the moment
I have to have in it the format of headers at some point. 
If that requirement goes away, the info could be stored 
as Word Perfect[1] documents for all I care. 



Adrian 

[1] long story...