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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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

Closed by  Pierre Schmitz (Pierre)
Tuesday, 29 March 2016, 16:23 GMT
Reason for closing:  Not a bug
Comment by Pierre Schmitz (Pierre) - Tuesday, 02 February 2016, 19:38 GMT
I don't see any bug here. Loading these extensions is a reasonable default. If you don't like those adjust your php.ini.
Comment by Bastien Traverse (Neitsab) - Thursday, 04 February 2016, 22:36 GMT
I agree it's not a bug per se, but since it is departing from upstream and you seemed to want to get closer to it with this release [1][2] I thought it could be a mistake/leftover.

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/
Comment by Pierre Schmitz (Pierre) - Tuesday, 29 March 2016, 16:23 GMT
Upstream only provides Windows packages and configuration. So we'll always deviate from that. There is no configuration that would fit every need. Otherwise it would not be configurable.

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.

Loading...