Theoretically, it's possible to include with the base package a script
that, given a path, would inspect the PHP code there and provide a list
of modules that should be enabled, based on the official list of modules
(http://php.net/manual/en/funcref.php) and the functions/classes list
for each. It won't be 100% reliable like C compilation/linking, but in
practice it could be a rather working approach for most users.
Even more theoretically, the base package could perform this operation
semi-automatically, e.g. take the PHP code paths from the configs
(though php could be started with alternative config via a cli param,
but this is not the mainstream case), then check it, then install needed
modules.
*From:* Stuart Henderson
*Sent:* Saturday, November 04, 2017 17:50
*To:* Martijn Van Duren
*Cc:* Antoine Jacoutot, Tom Van Looy, Robert Nagy, Ports, Kirill
Bychkov, Gonzalo L. Rodriguez, Marc Espie
*Subject:* Re: UPDATE: php revamp
On 2017/11/04 12:06, Martijn van Duren wrote:
On 11/03/17 21:56, Marc Espie wrote:> See, this is exactly what I'm afraid of.
run-time depends can be a bitch. The stuff still packages, and stays that
way until somebody notices an issue... which often happens a few months
after the commits, and sometimes even after release.
This risk should be minimal, since I grepped through all the packages
in-tree that contain a .php file on all the functions and classes that
moved out of main.
The problem is, people updating or importing any php-package need to do
the same. And then it's harder than doing a bulk search at the tine of
change. It's trickier than perl/python packages using modules, because
there are no build time checks.
