On 05/24/18 13:52, Stuart Henderson wrote:> It's definitely more than that - I know roundcube needs pdo_sqlite or > another pdo_* - you'd need to look for things using pdo at all to find > them, rather than just looking for sqlite. > The idea behind PDO is that the end-user can easily choose the backend (as long as the backend supports the used SQL-dialect). The use of the sqlite backend makes perfect sense for roundcube now, since it's embedded in the SAPI, but if we split it off we would always install a package that the user might not use. So I see a couple of options that are almost all equally valid to me: 1) We track down the packages that use pdo_sqlite and add it as a dependency, as you proposed. 2) We add it as a recommended dependency similar to what Debian's package manager offers. But do we even support something like that? 3) We leave it open and add a $MESSAGE to the package and a note to the readme. 4) Considering your remark about splitting up database extensions *with* library deps: For a future patch I would like to link our mysql modules to mysqlnd instead of libmysqlclient, because it fits better in php's memory_limit concept, supports returning of native integers and is also recommended[0]. That *could* be a reason to move the mysql modules back into the SAPIs and switch those that use sqlite now to mysql. I personally don't like this option, because it requires more administrative overhead to setup the mariadb instance, and merging the mysql interfaces could be interpreted as favouritism towards mysql over the other databases, where sqlite would be because its zero setup.
> Splitting up database extensions with library deps does seem reasonable > but I'm wondering maybe we should merge the $somedatabase and > pdo_$somedatabase packages, I'm not sure there's much point in splitting > them up, and that way the total number of subpackages doesn't increase.. > On first glance that would seem reasonable to me, but it would require a fair deal of refactoring. The current code assumes one package, one module, one auto-generated ini. Then there's also the problem with the fact that there's no 1 to 1 correlation between the module names: - sqlite3 / pdo_sqlite - mysql / mysqli /pdo_mysql - mssql / pdo_dblib - interbase / pdo_firebird (if we would ever enable it) So is the reduction of the packages worth the extra complexity? [0] http://php.net/manual/en/mysqlinfo.library.choosing.php
