[packages/php-pecl-http] - R += pecl-propro and pecl-raphf

[Elan Ruusamäe]

On 31.03.2015 18:34, Adam Golebiowski wrote:
> On Tue, Mar 31, 2015 at 05:35:45PM +0300, Elan Ruusamäe wrote:
>> On 31.03.2015 17:04, Adam Golebiowski wrote:
>>> [adamg at adamg ~]$ php -r ''
>>> PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php56/http.so' - /usr/lib/php56/http.so: undefined symbol: php_persistent_handle_abandon in Unknown on line 0
>>> [adamg at adamg ~]$ sudo mv /etc/php56/conf.d/{,z_}httpd.ini
>>> [adamg at adamg ~]$ php -r ''
>>> [adamg at adamg ~]$
>>>
>>> Not only we need these two, but we need them to load before http.so.
>>>
>>> Thinking about adopting apache-style prefixing with numbers:
>>> - 00-29 - core php modules
>>> - 30-99 - extra (pecl / non-pecl)
>> i've tried to postpone introducing numbering to ini files as long as
>> possible. because the numbering sucks(!).
> but it's easy and solves the problem.

creates problems elsewhere, need to migrate configs properly, and i hate 
when config files rename themselves, as i keep them in vcs.

>> maybe rename your ini file so that LC_ALL=C locale would sort it last:
>>
>> like:
>> http.ini -> http.ini (no changes)
>> propro.ini -> http_propro.ini
>> raphf.ini -> http_raphf.ini
> until we add some `boo' extension that depends on raphf, and that's just
> another version of prefixing.

but you need to handle only these two packages. not all 199 php-related 
packages, and don't even know when you need to reorder again because you 
guessed initial number wrong and *all* dependencies need to be shifted 
by some number.

and the schema is "<dependant_ext_name>_<current_ext_name>.ini which is 
quite clear after what to order.


>
>> ideally php-core should be smart itself (somehow) to be able to load
>> modules in different order based on dependencies.
>> possible solution would be to open shared library with lazy loading to
>> get dependency structure and then do the real open (with RTDL_NOW) after
>> dependency sort.
>> this is just theory, haven't tried.
> nice, but a bit overcomplicated.
> and we would end up maintaining yet another patch.
and what prevents submitting it upstream?

-- 
glen