Module yumpkg installing from source file uses rpm -qip, should use yum localinstall

[ghost]

If you need an .rpm installed on a minion, you can set up a state that looks something like this:

somepackage:
  pkg.installed:                                                                                                                
      - sources:
            - anRpmPackage: salt://resources/anRpmPackage.rpm

Provided that resource is valid, it gets transferred to the minion, where an rpm -qip $filename command gets run. The problem with this is that there is a dependency check involved, but no effort to install dependencies. This in particular is an rpm issue, not a salt issue.

However, when salt installs from this method, if it encounters dependencies, the installation fails, and salt barfs up a massive stack trace:

----------
    State: - pkg                                                                                                                
    Name:      elasticsearch
    Function:  installed
        Result:    False
        Comment:   An exception occurred in this state: Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/salt/state.py", line 1237, in call
    *cdata['args'], **cdata['kwargs'])
  File "/usr/lib/python2.6/site-packages/salt/states/pkg.py", line 386, in installed
    **kwargs)
  File "/usr/lib/python2.6/site-packages/salt/modules/yumpkg.py", line 501, in install
    **kwargs)
  File "/usr/lib/python2.6/site-packages/salt/modules/pkg_resource.py", line 291, in parse_targets
    problems = _verify_binary_pkg(srcinfo)
  File "/usr/lib/python2.6/site-packages/salt/modules/pkg_resource.py", line 195, in _verify_binary_pkg
    pkgmeta_name, pkgmeta_version = _parse_pkg_meta(pkg_path)
  File "/usr/lib/python2.6/site-packages/salt/modules/pkg_resource.py", line 114, in _parse_pkg_meta
    return metaparser(path)
  File "/usr/lib/python2.6/site-packages/salt/modules/pkg_resource.py", line 38, in parse_rpm
    pkginfo = _parse_pkginfo(pkginfo)
  File "/usr/lib/python2.6/site-packages/salt/modules/yumpkg5.py", line 71, in _parse_pkginfo
    pkginfo = collections.namedtuple('PkgInfo', ('name', 'version'))
NameError: global name 'collections' is not defined

        Changes:
----------

This can be avoided by having salt install local packages using yum localinstall $filename instead. This should install dependencies (provided the RPM file defines them).

I found issue #2291, describing the need for salt's ability to do installations from local package files, and it seems like that was mostly implemented, just without regard to dependencies.

[terminalmage]

rpm -qpi is used to check metadata ("q" for query, "p" for package, "i" for info, as noted in the manpage) and confirm that the package name matches the one specified. The traceback you're seeing above is a bug that has been fixed in 0.16.4 and has nothing to do with issues running rpm -qpi.

If you look at the source code for the install function in yumpkg5.py. yum install is used to resolve dependencies. yum localinstall has been deprecated for several years.

There is no bug here, that I can see.

[ghost]

Okay, maybe this is a misinterpretation, then. Should the minion be outputting the installation command it's running, or maybe the output of that command? The only thing I got was an error that looks like this:

2013-09-11 21:21:03,231 [salt.loaded.int.module.cmdmod][INFO    ] Executing command "rpm -qp --queryformat '%{NAME}_|-%{VERSION}_|-%{RELEASE}_|-%{ARCH}' '/var/cache/salt/minion/files/base/resources/elasticsearch-0.90.3.noarch.rpm'" in directory '/root'
2013-09-11 21:21:03,271 [salt.loaded.int.module.cmdmod][DEBUG   ] stdout: elasticsearch_|-0.90.3_|-1_|-noarch
2013-09-11 21:21:03,280 [salt.state       ][ERROR   ] No changes made for elasticsearch

Not sure what's causing the error. I checked for dependency problems with the package I was installing, and was able to install it just fine with no errors. Could be something's going on that I'm just not seeing, I suppose.

[terminalmage]

Pretty much every shell command run by the minion is logged at loglevel info. You are only seeing the output from the command because you are running your minion at the debug loglevel. Notice the DEBUG next to the command output.

Again, this is not an installation command. It's checking the binary package metadata to ensure that its name matches the one you've specified.

The traceback you are seeing is the same one as in #6677 and #6959 and, as I mentioned earlier, it has been fixed.