FS#47968 - [php] Some dynamic extensions are enabled by default at build time
Attached to Project:
Arch Linux
Opened by Bastien Traverse (Neitsab) - Sunday, 31 January 2016, 17:18 GMT
Last edited by Pierre Schmitz (Pierre) - Tuesday, 29 March 2016, 16:23 GMT
Opened by Bastien Traverse (Neitsab) - Sunday, 31 January 2016, 17:18 GMT
Last edited by Pierre Schmitz (Pierre) - Tuesday, 29 March 2016, 16:23 GMT
|
Details
Description:
curl.so and zip.so are the only two dynamic extensions enabled at build time. I wondered why since and noticed it was the result of generates_patches#29[1]. Since this line is a rather long variable declaration, I thought it could a typo. If it isn't, could you explain why those two extensions are enabled by default? Reason why I'm investigating this is to update ownCloud wiki page [2] which as of now prescribes to uncomment those two extensions, which are already uncommented. I noticed package_php() function in PKGBUILD depends on curl and libzip, but the local _phpextensions="" array doesn't seem to treat those specially. I also didn't find any info upstream, so sorry if I'm missing something. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/generate_patches?h=packages/php#n29 [2] https://wiki.archlinux.org/index.php/OwnCloud#Installation Additional info: * package version(s): php-7.0.2-2 |
This task depends upon
My main demand is just to know whether this reasonable default will be stable, or whether some other extensions will be enabled/disabled (like gettext in [3]).
Other reason I am asking is because different PHP apps require different extensions (MediaWiki requires gd, intl and iconv according to the wiki [4], while WordPress requires none [5]), and I thought it was more in line with the Arch way to let the user in charge of configuring their system. Disabling curl and zip would go a step further in KISS.
Finally, users of Apache, php-fpm and uWSGI (and probably others) have a way to enable php extensions per setup instead of doing so globally, and sometimes non-critical warning appear in the logs when an extension is enabled in both global php.ini and local env. Still, not really a bug, but not completely clean either.
Does enabling those two extensions by default have been requested or help with anything? Otherwise it's just another element users have to work with it seems.
[1] https://www.archlinux.org/news/php-70-packages-released/
[2] https://pierre-schmitz.com/php-7-on-arch-linux/
[3] https://projects.archlinux.org/svntogit/packages.git/commit/trunk/php.ini.patch?h=packages/php&id=3761a49a5cee67f756e852c2c00949de8665ef40
[4] https://wiki.archlinux.org/index.php/MediaWiki#PHP
[5] https://wordpress.org/about/requirements/
To answer your question:
* The default configuration wont be stable and may need to be adjusted at any time.
* It's based on personal experience and what other Distros are packaging. My personal benchmark is to make composer work with the default php package.
* KISS is no exact science but a compromise.