Re: Re: rpm-python legacy issues

Adrian Likins wrote:

>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. 
>  
>

"Only"? There is an immense gray area here imho. If you want to
do everything in Python, then I am certainly not going to stop you.

You appear to wish SWIG-like generated bindings rather than the current
rpm-python bindings to rpmlib. Dunno "scaleable" at all.

Whatever "hand crafting" there is in rpm-python has been done by others, 
not me.

I shall be happy to use SWIG if that is truly what you want for up2date. 
Not hard at all,
likely to be as good/bad/ugly -- and complete -- as rpmlib is too.

> 
>  
>
>>>       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. 
>  
>

Worked for me when I last used. Yes, totally undocumented and
unfinished, as I do not believe that any depsolver needs to be able to
configure rpm with the ease of a Python dictionary.

For example, you know well the pbrown comment that starts "XXX Gross, 
ugly hack ..."
that has resided in up2date code for years for what was, at the time, 
the one and only
addMacro call within up2date.

That pretty much sums up my feelings about designing a 
complex/convenient API for
configuring rpm. <shrug>

>
>  
>
>>>	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) 
>  
>

If all you want is more information returned on the gawd awful tuple return
from ts.check() regarding package "conflict info", I will be happy to
oblige.

No matter what, I need explicit sign off from major rpm-python users in 
a bugzilla report.
Start with sopwith, who is overly fond of the gawd awful ts.check() 
tuple return that is
currently simulated in rpm-python in order to keep beehive happy.

> 
>  
>
>>>	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...
>  
>

There are zillions of representations of metadata other than a Python 
header object.

Pick one, use it.

>  
>
>>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. 
>  
>

"headerlike object" is most easily achieved directly in python, and has
the advantage of never ending up in an rpmdb, thereby preventing screw-ups.

Go for it.

>	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).
>  
>

I have no idea how you plan to use current rpm-python bindings w/o
a transaction. If you know how, then, please, by all means, go for it.

>  
>
>>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. 
>  
>
Yes, a header object is needed for the call to ts.addInstallElement.

Yes, there are other uses of headers too.

Using "only headers" for everything is a different matter.

> 
>  
>
>>>	 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. 
>  
>

Again "only", with the claim "workable" too. Go for it.

I too have little use for XML except as a import/export or transport 
representation
of metadata.

I am certainly not denying you access to the contents of a header, you 
have access to
every bit in a header afaik.

If there is consensus that Word P{erfect is the best representation, 
then rpm-python
will use Word Perfect.

73 de Jeff