PHP-5.6 with PECL

[jkl]

My OpenBSD (5.8) server runs PHP 5.6. I would like to add the OAuth module from PECL, but the pear package is bound to PHP 5.4. How can I change that?

[jggimi]

What version and flavor of OpenBSD do you have installed? Looking through the port INDEX for OpenBSD 5.8, all of the pecl-* packages have a run dependency on PHP 5.6, and a dependency on www/pear, which itself is an independent and does not have any run dependencies.

At OpenBSD 5.7, the pecl-* applications were dependent on PHP 5.5.

At OpenBSD 5.6, the pecl-* applications were dependent on PHP 5.4.

[jkl]

I have OpenBSD 5.8 installed, filled entirely from the binary packages off the FTP mirrors and M:Tier. pkg_add pear still pulls and installs PHP 5.4 for me.

[jggimi]

Yes, I saw you mentioned 5.8 in your top post, just now. My mistake for missing it. But I am confused, because on a 5.8-stable system I have, I asked the ports tree what the run dependencies were, and it says:

$ cd /stable/usr/ports/www/pear
$ env PORTSDIR=/stable/usr/ports make print-run-depends
This port requires package(s) "femail-1.0p1 femail-chroot-1.0p2 xz-5.2.1
libiconv-1.14p3 gettext-0.19.5.1 libxml-2.9.2p7 php-5.6.17 
pear-utils-1.9.5p1" to run.

PHP did have -stable updates since 5.8-release, and this is a -stable ports tree I'm using. I'll grab a -release ports tree and see if the run dependency retains 5.6 for me, or reverts to 5.4.

[jggimi]

While that checkout of the tree is ongoing, I jumped on to my web server, which runs 5.8-stable. The pear package requires pear-utils, and the pear-utils package requires php-5.6.17. So that's the specific dependency chain.

[jggimi]

OK. The -release tree told me that there was a run dependency on php-5.6.11. As I'd expected, 5.4 wasn't mentioned.

As a second test, I installed a 5.8-release (amd64) test machine, and requested an installation of pear from my nearest mirror. 5.6.11 was the PHP version installed. Here's the log:

# pkg_add pear
quirks-2.114 signed on 2015-08-09T11:57:52Z
quirks-2.114: ok
pear-1.9.5p0:libiconv-1.14p3: ok
pear-1.9.5p0:gettext-0.19.5.1: ok
pear-1.9.5p0:xz-5.2.1: ok
pear-1.9.5p0:libxml-2.9.2p1: ok
pear-1.9.5p0:femail-1.0p1: ok
pear-1.9.5p0:femail-chroot-1.0p2: ok
pear-1.9.5p0:php-5.6.11: ok
pear-1.9.5p0:pear-utils-1.9.5p1: ok
pear-1.9.5p0: ok
Look in /usr/local/share/doc/pkg-readmes for extra documentation.
--- +php-5.6.11 -------------------
To enable the php-5.6 module please create a symbolic link from
/var/www/conf/modules.sample/php-5.6.conf to
/var/www/conf/modules/php.conf. As root:

    ln -sf /var/www/conf/modules.sample/php-5.6.conf /var/www/conf/modules/php.conf

The recommended php configuration has been installed to:
    /etc/php-5.6.ini.

I then removed all packages with pkg_delete -X, and began by explicitly installing php-5.4.43. And then installing pear. 5.6.11 was added as the dependency.

I can only make vague guess why you have this apparent dependency. A damaged package file? Doubtful, since the packages are cryptographically signed. Pointing to the wrong release of packages? Doubtful. You wouldn't be able to successfully install much. Damaged package database in /var/db/pkg? Possible. There is a pkg_check(8) consistency checker for that, which will check the database and also compare it to what it finds in /usr/local.

If you like, you could update from -release to -stable. Along with the PHP security updates from 5.6.11 to 5.6.17, the pear packages were rebuilt. An update might eliminate whatever the problem is you've encountered. And it would install security patches that -release does not have, both in the base system, and in any applicable third party packages such as PHP.

The Project does not build -stable packages or -stable systems; they leave that to end-users due to resource constraints. But there is a company that does build -stable systems and -stable packages as a service to the greater OpenBSD community: M:Tier. They have several OpenBSD developers on staff. https://stable.mtier.org.

[jggimi]

Ah, I see you're using M:Tier already, too.

Do you have any of the pecl-* packages installed?

[jggimi]

I downloaded the -release pear-utils package from my nearest mirror. This file is pear-utils-1.9.5p1.tgz. Within, the packing list (the +CONTENTS file) states the following:

@depend lang/php/5.6,-main:php->=5.6,<5.7:php-5.6.11

I'm now thinking you're not using the correct version of pear and pear-utils package.

Of course, all this thread has really proven is my comprehension is poor. I missed your release, and I later missed you were already using -stable components from M:Tier.

[jkl]

Well ...

No, I don't have any pecl- package installed. I only need OAuth from PECL and that's not a separate package.

But somehow you're right:

> pkg_info pear-utils
Information for http://ftp.spline.de/pub/OpenBSD/5.6/packages/amd64/pear-utils-1.9.4p2.tgz

That's ... weird, because:

PKG_PATH=http://ftp.eu.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(arch -s)
PKG_PATH=https://stable.mtier.org/updates/$(uname -r)/$(arch -s):${PKG_PATH}
export PKG_PATH

and:

> uname -r
5.8

Now I'm lost.

[jkl]

Ha, investigating it further... I had a very, very old(ish) /etc/pkg.conf (whyever) with a very, very old(ish) installpath laying around.

> pkg_add pear-utils
quirks-2.114 signed on 2015-08-09T11:57:52Z
pear-utils-1.9.5p1: ok

Perfect!

Thank you for helping me to think further, after all.

[jggimi]

Hmmm. The pkg.conf(5) file will only be used if the $PKG_PATH environment variable is unset. So it's possible your PKG_PATH was not set at the time you were running pkg_add(1). That's possible, if you have it set in your unprivilege user's environment and you use doas(1) or security/sudo for privilege escalation. The doas.conf(5) and sudoers(5) configuration files can control environment passing.

[jkl]

I keep my PKG_PATH in /root/.profile and usually use su (rarely doas) to perform package operations - is that wrong?

Indeed, echo $PKG_PATH is empty from su.

[jggimi]

No, there's nothing wrong with using su(1). I was just trying to explain a possibility in the event you happened to have $PKG_PATH provisioned, but were unable to successfully pass it to pkg_add().

You had mentioned having an apparent correctly configured environment variable, but then found pkg_add() using an outdated pkg.conf(5) instead.