Closed daverogers closed 5 years ago
Meh.
PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/cassandra.so' - /usr/lib64/php/modules/cassandra.so: cannot open shared object file: No such file or directory
PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/yaf.so' - /usr/lib64/php/modules/yaf.so: cannot open shared object file: No such file or directory
Nobody else is seeing this? Upgraded to 5.1 and bam, broken. Disappointing.
Adding channel 'pecl.php.net'
to the php_pear resource indeed works to get the extension compiled, but the extension doesn't get configured (no ini put in place, no phpenmod on debian/ubuntu)
Also v5.1.0 is missing the node['php']['pear']
attribute introduced by #229 so it looks like v.5.1.0 is just generally broken.
The reason the ini doesn't get put in place is because the logic behind the pecl?
function has changed.
in <= v4.6.0 the logic was this:
if grep_for_version(shell_out(node['php']['pear'] + search_args).stdout, @new_resource.package_name)
false
elsif grep_for_version(shell_out(node['php']['pecl'] + search_args).stdout, @new_resource.package_name)
true
else
raise "Package #{@new_resource.package_name} not found in either PEAR or PECL."
end
In >= v5.0.0 the logic changed to:
if grep_for_version(shell_out(new_resource.binary + search_args).stdout, new_resource.package_name)
false
elsif grep_for_version(shell_out(node['php']['pecl'] + search_args).stdout, new_resource.package_name)
true
else
raise "Package #{new_resource.package_name} not found in either PEAR or PECL."
end
This is all fine if you consider that new_resource.binary
defaults to pear
anyway. In that case there is no change in the logic (it will check pear with desired state stable in the default channel pear.php.net for a particular extension, and if there is a hit, it will return false to indicate that this is a pear package instead of a pecl package)
So as long as you don't set the channel to 'pecl.php.net' all goes well. If you do set the channel to pecl.php.net (as we do to get the package to install at all) it will run pear -d preferred_state=stable search -c pecl.php.net <packagename>
, which will result in a positive hit, but the first if condition in the pecl?
function will return false.
Having to set the channel to get pecl extensions to install at all is caused by the removal of a bit of logic when the providers were converted into custom resources. The old providers used to have this bit of logic in the load_current_resource
method to be sort-of-smart on detecting if something is pecl or pear and override which binary to use accordingly. See https://github.com/chef-cookbooks/php/blob/056687236d246d98df7f6afcdfdf3481b61ea037/providers/pear.rb#L113 for that
@bin = node['php']['pear']
if pecl?
Chef::Log.debug("#{@new_resource} smells like a pecl...installing package in Pecl mode.")
@bin = node['php']['pecl']
end
@hrak the PECL module should work on ubuntu with #245 . I added some PECL examples to README.md, which currently require a binary
or channel
param for PECL packages
Hi,
I am closing this issue as it is reported as resolved, if it is not please do re-open it
Thanks
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Cookbook version
5.1.0
Chef-client version
13.2.20
Platform Details
Vagrant 2.0.2 running CentOS 7.3
Scenario:
Installing PECL packages
Steps to Reproduce:
Expected Result:
Install packages, as it always did before :P
Actual Result:
CONCLUSION
When I added
channel 'pecl.php.net'
it worked fine. So it looks like ya'll just need to update the documentation if this is the intended behavior, or also search the PECL channel by default (how I assume it used to work?). Otherwise, the documented examples will not work, because those are not PECL libraries (xdebug, apc, etc.)