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

Hi all,
 so I've been thinking some about the ts.check() call and other ways of
resolving deps for a transaction set.

right now ts.check() hands back a list of tuples

the tuple looks something like:

((name, ver, rel), (needname, needversion), flags, suggest, sense)

sense is conflicts or requires

name, ver, rel are the n-v-r of the package that needs or conflicts with
something

needname and needversion are the name and evr of the thing that (n-v-r,
above) conflicts with or requires

suggest is a header object of what package will resolve the problem

flags is the flag for the relationship of needname and needversion.



There are multiple problems with this:
1. There is insufficient information there for depresolution for a
multiarch machine. You don't know the arch of the requiring package so
you have to make certain guesses to figure out which needs which.

2. There is no room for expansion of information in this format: it's a
tuple, it has to be a certain size and/or things have to be in a precise
place - add a field, remove a field, and things will break.


So what should we do?

It might make sense to have ts.check() hand back a list of dicts that
has keys being the above items and more. Then as time goes on if we need
more fields adding them won't break backward compat.

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

etc etc etc

Either of those would allow for expansion for the future and I don't
think they are overly heavy to pack.

Thoughts?

What to people think about the depcheck callback that exists, is that
functional enough to completely obsolete the tuple from ts.check()?

-sv