Fails when the package name is not the install directory for system provider.

[nmaki]

When using the system provider to install the python34 package from the EPEL repo on Centos7 the cookbook fails. The system provider assumes that the binary will install with the same name as the package name which is incorrect in this case as the python34 package will install the binary to '/usr/bin/python3.4' while the cookbook expects to find it at /usr/bin/python34. Could an option be added to specify the expected binary?

[coderanger]

You can work around this locally by installing the package normally via Chef and then set the python_runtime resource to use the :dummy provider, which has manual overrides for the python_binary path. Not sure what the best way to handle this would be. I'm guessing you have to override the package_name to get it to use this package at all? Probably would be right to have a provider for EPEL, but unless you have a really good reason you should probably use the SCL packages before EPEL :)

[maxwell-gregory]

I'd like to add to this. Just like you stated, yes, you have to "override the package_name to get it to use this package at all" at least in my case.

A fix for this would be nice. SCL repo does not work in our environment our yum is very locked down so manually finding and building our repo is necessary. I think supporting EPEL or other custom repositories is necessary.

Now I am stuck at getting pip installed for this dummy provider, it seems to not care.