Re: ts.check() and ways of getting unresolved dependencies from a ts

Sean Dilda <[email protected]> Mon, 11 Oct 2004 11:21:33 -0400
Newsgroups gmane.linux.redhat.rpm.python
Message-ID <1097508092.11520.14.camel@pel>
On Mon, 2004-10-11 at 11:05, seth vidal wrote:

> We could also have ts.check() return a list of 'tsproblem' objects.
> 
> These objects could have attributes like:
> problem.type - sense
> problem.need - needname/version/whatever
> problem.whatneeds - header object of the package that is 
>                     needed/conflicted, what have you
> 

For the most part, I like this idea.  Especially with special objects,
as opposed to just dictionaries (this is for cosmetic as well as
backwards compatibility reasons).

This reminds me of how the output of os.stat() was changed in the core
python libraries.  Originally it returned a tuple.  Not it returns an
object that acts much like you're describing.  But they also made it
backwards-compatible by making the new object indexable in the same way
the tuple was.  I suggest following their lead and have it return a list
of these new backwards-compatible objects.

I do have one other concern.  I haven't looked at rpm-python in a while,
so I'm not certain.. but is there a standard way of representing
name-epoch-version-release in rpm-python?  If so, the new objects should
of course follow that.  If there isn't a standard way, maybe we should
look into coming up with one.