Bug in yum post-transactions-actions plugin

[James Antill]

On Tue, 2013-12-03 at 15:57 +0000, Gerry Kavanagh wrote:
> Hi James...
> I believe there is a bug in post-transactions-actions yum plugin, v
> 1.1.30-14-el6, from the RHEL Optional repo.
> The following trigger is created
> in: /etc/yum/post-actions/litp.action 
> 
> /opt/ericsson/nms/litp/lib:any:service litpd restart
> 
> When I execute the trigger on 'remove' I see the following behaviour:
> 
> [root at ms1 ~]# yum erase -y ERIClitplibvirt_CXP9030547
> Loaded plugins: post-transaction-actions, product-id, subscription-manager
> This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
> Setting up Remove Process
> Resolving Dependencies
> --> Running transaction check
> ---> Package ERIClitplibvirt_CXP9030547.noarch 0:1.0.44-1 will be erased
> --> Finished Dependency Resolution
> 
> Dependencies Resolved
> 
> ===============================================================================================================================================================================
>  Package                                                 Arch                                Version                                  Repository                          Size
> ===============================================================================================================================================================================
> Removing:
>  ERIClitplibvirt_CXP9030547                              noarch                              1.0.44-1                                 @LITP                               24 k
> 
> Transaction Summary
> ===============================================================================================================================================================================
> Remove        1 Package(s)
> 
> Installed size: 24 k
> Downloading Packages:
> Running rpm_check_debug
> Running Transaction Test
> Transaction Test Succeeded
> Running Transaction
>   Erasing    : ERIClitplibvirt_CXP9030547-1.0.44-1.noarch                                                                                                                  1/1 
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 29, in <module>
>     yummain.user_main(sys.argv[1:], exit_code=True)
>   File "/usr/share/yum-cli/yummain.py", line 285, in user_main
>     errcode = main(args)
>   File "/usr/share/yum-cli/yummain.py", line 219, in main
>     return_code = base.doTransaction()
>   File "/usr/share/yum-cli/cli.py", line 586, in doTransaction
>     resultobject = self.runTransaction(cb=cb)
>   File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1590, in runTransaction
>     self.plugins.run('posttrans')
>   File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 184, in run
>     func(conduitcls(self, self.base, conf, **kwargs))
>   File "/usr/lib/yum-plugins/post-transaction-actions.py", line 134, in posttrans_hook
>     thispo = _get_installed_po(rpmdb, txmbr.pkgtup)
>   File "/usr/lib/yum-plugins/post-transaction-actions.py", line 67, in _get_installed_po
>     return rpmdb.searchNevra(name=n, arch=a, epoch=e, ver=v, rel=r)[0]
> IndexError: list index out of range
> [root at ms1 ~]#
> 
> I understand that you may not be the person to address this to, but
> can't find a bug tool for this plugin.

 You can log bugs for it against the yum-utils package, and/or talk
about it on the yum-devel mailing list. Saying that, I probably know the
most  about it so you'll probably end up with me anyway :).

 It's been a long time since I looked at this plugin and I didn't write
it, but that bit does look wrong (it looks like it'll try and search for
any package that is removed, after it is removed) ... although it's been
around for a few years now, so if it's wrong as it looks I'm surprised
nobody has seen it earlier :-o.
 Assuming that is the problem, it's possible that we are removing a
cache sooner now in yum ... so before the plugin was getting the
(cached) old rpmdb entry (from before the transaction happened) and now
we've wiped that it's failing. Or maybe more likely the po.state should
be updating to REMOVED and isn't anymore.
 My guess is it's trying to do some optimization so that accessing
thispo.filelist doesn't trigger a filelist metadata download.

 Can you confirm that it's looking for the package that is being
removed?

 If you turn off post transaction actions is the package remove failing
in anyway?