|Summary:||yum localinstall throws: ValueError: <any rpm> has no attribute basepath|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Michal Karm Babacek <mbabacek>|
|Component:||yum||Assignee:||Valentina Mukhamedzhanova <vmukhame>|
|Status:||CLOSED ERRATA||QA Contact:||Marek Marusic <mmarusic>|
|Version:||6.4||CC:||akostadi, james.antill, jzeleny, mbabacek, mmarusic, vmukhame|
|Fixed In Version:||yum-3.2.29-61.el6||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-07-22 07:21:07 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Michal Karm Babacek 2013-10-07 15:32:14 UTC
Dearest, we managed to get a fresh RHEL 6.4 box to a state, when any attempt to localinstall fails with: ValueError: your.rpm has no attribute basepath For instance, yum localinstall ~/rpm/* --disablerepo=beaker-* results in: http://pastebin.com/v1LLWyQh The events preceding this state consisted purely of registering to RHN channels, doing yum groupinstall, remove, update, install. No manual configuration of yum whatsoever. I will share the exact log internally. THX 4 any info
Comment 3 Zdeněk Pavlas 2013-10-08 11:18:01 UTC
While I have no idea where yum-checksum plugin comes from (it's neither from "yum" or "yum-utils"), it very likely just treats YumLocalPackage instances as YumAvailablePackage instances. The following patch should fix this issue on Yum side. diff --git a/yum/packages.py b/yum/packages.py index deb44e4..042a50b 100644 --- a/yum/packages.py +++ b/yum/packages.py @@ -1333,6 +1333,9 @@ def _rpm_long_size_hack(hdr, size): # which are actual rpms. class YumHeaderPackage(YumAvailablePackage): """Package object built from an rpm header""" + + remote_url = '<local>' + def __init__(self, repo, hdr): """hand in an rpm header, we'll assume it's installed and query from there"""
Comment 4 Aleksandar Kostadinov 2013-10-08 13:31:32 UTC
Zdeněk, this is a plug-in to help us verify our RPMs are what we actually expect them to be. Here is the plug-in source: https://svn.devel.redhat.com/repos/jboss-qa/beaker/trunk/eap/6.2/yum_checksum.py I'm not an expert, this is first thing I write in python and first thing I write for yum. So please let me know if something is wrong. It just logs the sha1 of every installed package through yum. Thank you!
Comment 5 Zdeněk Pavlas 2013-10-08 13:50:08 UTC
Np, the plugin code seems correct, it just does not handle local packages. pkg.remote_url is probably the only problem there. My patch from comment 3 should work this around. Alternatively, you can fix the plugin with something like: --- yum_checksum.py.orig 2013-10-08 15:43:05.592878389 +0200 +++ yum_checksum.py 2013-10-08 15:45:57.386388083 +0200 @@ -52,6 +52,10 @@ for pkg in conduit.getDownloadPackages(): # see remote_url() and checksum() fname = pkg.localPkg() - log.write('%s %s %s %s %s\n' % (hashfile(fname), fname, pkg.name, pkg.checksum, pkg.remote_url)) + if getattr(pkg, 'pkgtype', None) == 'local': + url = '<local package at %s>' % fname + else: + url = pkg.remote_url + log.write('%s %s %s %s %s\n' % (hashfile(fname), fname, pkg.name, pkg.checksum, url)) finally: log.close()
Comment 6 Aleksandar Kostadinov 2013-10-08 14:17:23 UTC
Zdeněk, thank you for the advice. I see value in your patch to packages.py because the fact that a package is local does not mean it should not have an URL defined as well it's easier to code plug-ins wen attributes are always there. Do you think your patch will go upstream or should I use the method you suggest above to fix for yum_checksum only? btw I think it will be most straightforward to have packages.py like: > remote_url = 'file://' + urllib.pathname2url(os.path.abspath(pkg.localPkg())) because otherwise url would not really be an url and next time I decide to write some weird plugin incarnation of non-sense it may break again.. WDYT?
Comment 7 Zdeněk Pavlas 2013-10-08 15:45:18 UTC
If you need to track the package source, then file:// URL would certainly help. I was just trying to return a dummy string instead. http://lists.baseurl.org/pipermail/yum-devel/2013-October/010387.html
Comment 8 Zdeněk Pavlas 2013-10-09 10:27:36 UTC
Merged upstream. http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=da3b4624
Comment 9 RHEL Program Management 2013-10-13 23:03:27 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
Comment 10 Aleksandar Kostadinov 2013-10-16 13:05:21 UTC
Zdeněk, I tried your suggested patch but it fails badly for me: > if getattr(pkg, 'pkgtype', None) == 'local': > File "/usr/lib/python2.6/site-packages/yum/sqlitesack.py", line 270, in __getattr__ > raise KeyError, str(e) > KeyError: 'no such column: pkgtype' This is RHEL6 but I need it working on RHEL5 as well. Since your other patch will not be backported to RHEL at least for the time being, I thought it's better to have a fix locally.
Comment 11 Aleksandar Kostadinov 2013-10-16 13:06:00 UTC
Forgot to say I'm seeing the error trying to install a package from remote repo.
Comment 12 Zdeněk Pavlas 2013-10-16 13:31:44 UTC
Sorry, was too quick writing this. Try to replace the above with: - if getattr(pkg, 'pkgtype', None) == 'local': + if hasattr(pkg, 'pkgtype') and po.pkgtype == 'local': Usually these are equivalent, but sqlitesack overrides __getattr__ ..
Comment 13 Aleksandar Kostadinov 2013-10-16 13:39:32 UTC
Comment 14 Zdeněk Pavlas 2013-10-16 14:39:16 UTC
+ if hasattr(pkg, 'pkgtype') and pkg.pkgtype == 'local': ..to fix the obvious copy-paste error.
Comment 15 Michal Karm Babacek 2014-11-06 14:19:02 UTC
Guys? Ain't we gonna close this one or something? :-)
Comment 16 Jan Zeleny 2014-11-07 07:46:50 UTC
Not yet. It seems simple enough, I'm proposing this to be fixed in RHEL 6.7 ...
Comment 23 errata-xmlrpc 2015-07-22 07:21:07 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1384.html