Re: How many pecl packages have an different extension name from the package?

Wez Furlong wrote: >Hi Greg, > >Each different extension provides a PDO driver with a different name >(the idea is that it is theoretically possible to load all three >different implementations into a given process and make use of them). > > ok, this is good then, because the way I have things set up, this is a package2.xml dependency on a pecl package that would cover our bases with a standard single-ext package like sqlite: <package> <name>SQLite</name> <channel>pecl.php.net</channel> <providesextension>sqlite</providesextension> </package> When the installer is verifying this dep, it does a 3-step check and exits with an OK if any check out: 1) is sqlite loaded in memory? 2) is the pecl.php.net/SQLite package -or- the pear.php.net/SQLite package being downloaded for installation (the user typed "pear install Somepackage pecl/SQlite") 3) is the pecl.php.net/SQLite package -or- the pear.php.net/SQLite package installed? If all fail, the dependency fails. This, incidentally, is why the new pecl command is available. Unlike the pear command, pecl disables use of php.ini, essentially unloading all dynamic modules so that they can be upgraded. So, in this case, if sqlite was installed through the pecl/pear command sqlite would not be in memory, but the package would be in the registry. For pecl packages like PDO that have drivers/subpackages, even if PDO is distroed with PHP, installation will still work when php.ini is disabled and the PDO extension is not in-memory, as upgrading a driver will simply require a pecl-based installation of PDO, a task that can either be done by installing it and building it again, or through: $ pecl install --register-only PDO Which will download/build/register but not actually overwrite anything that is already there. Just to verify, what you're saying is that this dependency is perfectly valid for pdo_dblib: <package> <name>PDO_DBLIB</name> <channel>pecl.php.net</channel> <providesextension>pdo_mssql</providesextension> <providesextension>pdo_sybase</providesextension> <providesextension>pdo_dblib</providesextension> </package> This would perform these steps: 1) check for extensions in memory a) is pdo_mssql loaded in memory? b) is pdo_sybase loaded in memory? c) is pdo_dblib loaded in memory? 2) is the pecl.php.net/PDO_DBLIB package -or- the pear.php.net/PDO_DBLIB package being downloaded for installation (the user typed "pear install Somepackage pecl/PDO_DBLIB") 3) is the pecl.php.net/PDO_DBLIB package -or- the pear.php.net/PDO_DBLIB package installed? However, there is an issue that dependencies cannot solve: if someone writes an app that can only work with pdo_mssql and not pdo_sybase/pdo_dblib, then this must be verified in the code itself, as there is no way to register which extensions are actually provided by the package based on the PEAR registry. Unless you think this is a problem, I'm not too concerned, as someone writing code that specific is going to need to put in a "extension_loaded('pdo_sybase')" check in the code anyways. Does this look good? I will implement this functionality in 1.4.1 (it's a simple and easy change) if so. >PDO_OCI, on win32, can build php_pdo_oci.dll and php_pdo_oci8.dll >which are identical except that php_pdo_oci8.dll is linked against an >older version of the OCI libraries. In this case, the driver name is >the same, so you can only load one version or the other into your >process. > This sounds like it will work just fine with the existing mechanism, as there is only 1 actual extension name distributed with the package. Greg