[packagekit] yum: detecting file conflicts and using a custom error

[Robin Norwood]

On Mon, 14 Apr 2008 15:49:42 +0100
Richard Hughes <hughsient at gmail.com> wrote:

> On Mon, 2008-04-14 at 15:48 +0200, Tim Lauridsen wrote:
> > Not in this case, yum call rpm to test a transaction and rpm
> > returns a return code and a list of errors, if there is an error
> > then yum raises a exception with the list of errors generated by
> > rpm. It didn't knows what kind of errors it is.
> 
> Well, we need to parse the proper error types in a fine grained way,
> see below.
> 
> > I don't know all the errors rpm can return in this case, starting
> > to parse the string, really sucks big time and i don't see the
> > benefit of doing it, we have an error we can't solve, we cant do
> > any thing else than abort the task.
> 
> Well, instead of presenting "unknown error" we can present "There were
> file conflicts". Now, you might think that's a waste of time, seeing
> as you can see that in the error details, but if you localise the UI
> to German, the description becomes some foreign gibberish.

I agree that this should be done, but the lower in the stack the
better.  Ideally, yum (or better, rpm) would be fixed to give better
errors...however, the problem here is that instead of getting one
specific exception, yum can get multiple errors per transaction from
RPM. This doesn't fit well with the exception model.  If you must have
a specific exception, the best we could do with the current system is
pick the first and throw away the rest, which might not be the most
severe.  Another alternative is if PK started allowing multiple
ErrorCodes per transaction, we could split the transaction errors and
dump them on you that way.  This could be a *lot* of errors, though, so
we would almost certainly want some way to bundle them up somehow.
(Popping up 145 different windows when a transaction has 145 errors
would be...bad).

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching