Bug 474106 - Updates instance has no attribute 'obsolete'
Updates instance has no attribute 'obsolete'
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
10
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-02 04:00 EST by Bojo Recko
Modified: 2014-01-21 18:07 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-03 05:16:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bojo Recko 2008-12-02 04:00:27 EST
Description of problem:
As I have reported this bug on bugs.freedesktop.org
(see https://bugs.freedesktop.org/show_bug.cgi?id=18830) and was redirected here:

Soon after log-in to KDE I get this error message:

Error Type: <type 'exceptions.AttributeError'>
Error Value: Updates instance has no attribute 'obsoletes'
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 2202, in
<module>
    main()
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 2199, in main
    backend.dispatcher(sys.argv[1:])
  File : /usr/lib/python2.5/site-packages/packagekit/backend.py, line 599, in
dispatcher
    self.dispatch_command(args[0], args[1:])
  File : /usr/lib/python2.5/site-packages/packagekit/backend.py, line 507, in
dispatch_command
    self.get_updates(filters)
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1735, in
get_updates
    ygl = self.yumbase.doPackageLists(pkgnarrow='obsoletes')
  File : /usr/lib/python2.5/site-packages/yum/__init__.py, line 1527, in
doPackageLists
    for (pkgtup, instTup) in self.up.getObsoletesTuples():
  File : /usr/lib/python2.5/site-packages/rpmUtils/updates.py, line 568, in
getObsoletesTuples
    obslist = self.obsoletes.keys()

This happened immediately after upgrading from Fedora 9 to Fedora 10 using
preupgrade utility. Using 2.6.27.5-117.fc10.i686, KDE 4.1.3 on Dell Inspiron
8600.


Version-Release number of selected component (if applicable):
Fedora 10 (2.6.27.5-117.fc10.i686)
KDE 4.1.3
yum 3.2.20-3.fc10

How reproducible:
Login to KDE 4.1.3 and after some time the message pops up 

Steps to Reproduce:
1.Login to KDE 4.1.3
2.Wait several minutes
3.
  
Actual results:
Error message (a cloud on the lower right) with the above message

Expected results:


Additional info:
Updating system form Kyum works fine

The error message which was reported to bugs.freedesktop.org (as suggested by error message, but Mr. Richadd Hughes has asked to file it with you).
Comment 1 Richard Hughes 2008-12-02 05:24:46 EST
The yum code should not emit a low level exceptions.AttributeError, and instead emit yum.Errors.RepoError or something sensible like that.

YUM needs to handle it's own exceptions. PackageKit can't try to catch everything from the internals of yum. Please do not re-assign this to PackageKit.
Comment 2 James Antill 2008-12-02 10:30:03 EST
 NO ... we aren't ever going to catch all exceptions and convert them into something they aren't so you can catch them ... live with it. Doing so would be like sticking a longjumnp handler in the middle of a library and using it to return a "error, random crash happened".

 This isn't a "catchable" exception, you've (indirectly) called getObsoletesTuples() without calling doObsoletes() ... and it doesn't work.
 Now, sure you can argue that we should hasattr() it and auto. init. ... that's fine, we'll probably accept a patch to do that. But atm. PK is wrong, fix it or close WONTFIX ... I'm not sure I care which.
Comment 3 Richard Hughes 2008-12-02 10:55:24 EST
(In reply to comment #2)
>  NO ... we aren't ever going to catch all exceptions and convert them into
> something they aren't so you can catch them ... live with it. Doing so would be
> like sticking a longjumnp handler in the middle of a library and using it to
> return a "error, random crash happened".

No, it would be a case of writing a library that chained up exceptions to give a useful error to the user.

>  This isn't a "catchable" exception, you've (indirectly) called
> getObsoletesTuples() without calling doObsoletes() ... and it doesn't work.

Right, so you need to throw an exception. Just allowing a traceback is a poor show. doObsoletes should have been called in self.yumbase.doPackageLists(pkgnarrow='updates') -- but the code is so difficult to follow I'm not sure.

>  Now, sure you can argue that we should hasattr() it and auto. init. ... that's
> fine, we'll probably accept a patch to do that. But atm. PK is wrong, fix it or
> close WONTFIX ... I'm not sure I care which.

No, this isn't an issue with what PK is or isn't doing. If you use a library in an unexpected or incorrect way, you're meant to get an error, not just for the library to explode in some obscure or internal place. There's also so little documentation for the public methods I'm not surprised we keep getting it wrong.

YUM isn't just a command line tool, it's an infrastructure that other tools build on. I can't just do around _every_ yum method:

        try:
            yb.someting()
        except Exception, e:
            self.error(ERROR_INTERNAL_ERROR, _to_unicode(e))

As this doesn't tell the user what went wrong. YUM needs to be fixed.
Comment 4 Richard Hughes 2008-12-02 13:33:35 EST
Bojo, sorry to get you caught up in the politics. Could you give the rpm's at http://www.packagekit.org/packages/ a go and tell me how you get on?
Comment 5 Bojo Recko 2008-12-03 07:14:14 EST
(In reply to comment #4)
> Bojo, sorry to get you caught up in the politics. Could you give the rpm's at
> http://www.packagekit.org/packages/ a go and tell me how you get on?

Installing above rpms (using yum) I have problems with dependencies (mind you I am not a Linux expert). I tried to install PackageKit-0.4.0-0.1117.20081202git.fc10.i386.rpm but got error messages saying: 

PackageKit-qt-0.3.9-4.fc10.i386 from installed has depsolving problems                                                                                               
  --> Missing Dependency: PackageKit = 0.3.9-4.fc10 is needed by package PackageKit-qt-0.3.9-4.fc10.i386 (installed)
...

then tried to install PackageKit-yum-plugin-0.4.0-0.1117.20081202git.fc10.i386.rpm and got error message saying: 

PackageKit-0.3.9-4.fc10.i386 from installed has depsolving problems
  --> Missing Dependency: PackageKit-yum-plugin = 0.3.9-4.fc10 is needed by package PackageKit-0.3.9-4.fc10.i386 (installed)
Error: Missing Dependency: PackageKit-yum-plugin = 0.3.9-4.fc10 is needed by package PackageKit-0.3.9-4.fc10.i386 (installed)

The fact is that PackageKit-yum-plugin-0.3.9-4.fc10 is installed but yum says it is missing.

I am quite happy to wait new version of PackageKit makes it to Fedora repository. On the other hand if I can help I am quite willing to participate but might need more detailed instructions due to my level of knowledge. Rgrds, Bojo
Comment 6 Richard Hughes 2009-01-14 08:37:41 EST
commit bc30cd1adfd00cad4260757291cc5ebddcabe6d7
Author: Richard Hughes <richard@hughsie.com>
Date:   Thu Dec 4 10:13:33 2008 +0000

    yum: as we can't treat yum like a usual python module, hand-hold it by wrapping all calls in 'except Exception' and throwing an internal error. This sucks.

:100755 100755 657cdcd... 03c02b4... M	backends/yum/yumBackend.py
:100755 100755 fedc171... 9c77785... M	backends/yum/yumComps.py
Comment 7 seth vidal 2009-01-14 08:51:44 EST
Wow, glad you're not trying to be rude or anything.

Professional, really.
Comment 8 Richard Hughes 2009-01-14 09:16:27 EST
(In reply to comment #7)
> Wow, glad you're not trying to be rude or anything.

I'm not trying to be rude, in fact I apologise if it came out like that. I'm being blunt. The error handling in yum is not good, and so I'm having to treat it unlike the other python modules.

Note You need to log in before you can comment on or make changes to this bug.