On Mon, Dec 22, 2008 at 10:34:55PM +0100, Dag Wieers wrote:
On Mon, 22 Dec 2008, James Antill wrote:
On Mon, 2008-12-22 at 12:29 -0800, Akemi Yagi wrote:
On Fri, Dec 12, 2008 at 4:56 PM, Karanbir Singh mail-lists@karan.org wrote:
[...]
File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, in _sql_pkgKey2po pkg = self._packageByKey(repo, ob['pkgKey']) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, in _packageByKey po = self.pc(repo, cur.fetchone()) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, in __init__ self._read_db_obj(db_obj) File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, in _read_db_obj setattr(self, item, _share_data(db_obj[item])) TypeError: unsubscriptable object
This is more understandable upstream by:
http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3120676a73219b018d317...
...which gives a "nice" message. There is also a change to yum-metadata-parser, which should work around the problem in atrpms. The short term. fixes are:
Don't use atrpms.
Use "yum clean metadata"
Can you be a little bit more specific ? Is there a thread describing the issue ? Is there going to be a real fix for it ?
I really don't feel good with this patch. The error does not indicate to a user that a "yum clean metadata" resolves their problem.
If we are going to have all our users that use atrpms go through this by default, then I think we should avoid it at all cost.
I also don't understand the patch mentioned above. What at ATrpms upsets the new yum that way? If it's something I can fix on my end, I'd gladly do so, but I'm just using plain createrepo (and this seems to work with the yum version in question with other distros).