Re: rpm-python legacy issues

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.

IMHO, this is the wisest approach to legacy issues. All
users of rpm-python need to avoid biting into rpm's
checkered legacy, and I see no way to put the rpm
Humpty back together again, ever. 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)

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.


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


>	bindings to anything the commandline can
>	do (aka, -V, for an obvious example)\

Embedding the rpm CLI is the most expedient answer, as there is
more than verify that needs access.

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

There is already a ts.run() call with RPMTRANS_BUILD_PROBS
(whatever, you know the details), that can be used to extract
"conflict info". It's up to rpm-python users to choose
if/when they wish that info, and where to extract.

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

Alas, this is a finit, but non-trivial, amount of work.


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

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.

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.

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

(various other intelligent and thoughtful comments deleted)

73 de Jeff