08.06.2015
В то время, когда космические корабли бороздят просторы Большого Театра, а сообщество перловиков ждет, когда же в едином порыве сойдутся mod_perl2 и Apache 2.4, Contenido продолжает использовать Apache 1.3 и mod_perl 1.31.
Почему?
Неоднократно и по-разному проведенные тесты показали, что никакой разницы в быстродействии при переходе от Apache 1.3 к Apache 2.2 и Apache 2.4 нет. Нет разницы в быстродействии у mod_perl1, mod_perl2 и fast-cgi. Зато есть большое количество структурных проблем, обнаруженных при попытке перевода Mason с mod_perl1 на mod_perl2. Первая из них – отваливающаяся магия dhandler. Второй mod_perl больше не пытается обрабатывать обращения к ссылкам, оканчивающимся на '/', и передает управление в mod_index; в результате dhandler просто не получает управление. Рекомендации по обходу данной проблемы, указанные в документации, в общем случае, не работают. Почему – выяснить пока не удалось.
В итоге, пока процесс перехода на Apache 2.2 буксует, оказалось, что проще пройтись по списку найденных и исправленных багов в mod_perl и сделать набор патчей для конфигурационных файлов с тем, чтобы Contenido можно было развернуть на старших версиях Perl. В настоящий момент "окучены" Perl 5.14 (Bug #68233 for mod_perl: mod_perl not install with perl 5.14) и 5.16.хх (Bug #77129 for mod_perl: PL_uid breakage on 5.16.0 и Bug #79977 for mod_perl: mod_perl cannot be built on Perl 5.16).
Кроме того, обнаружено, что в более новых версиях gcc изменен умолчательный метод оптимизации для инлайновых функций, что привело к невозможности вкомпилировать mod_perl в Apache.
Результатом стал набор патчей для apache, mod_perl и libapreq, автоматический прикладываемый при необходимости, и обеспечивающий установку на системы с Perl версий 5.16.xx и gcc версии 4.3 и выше. Эксперименты по установке на 5.17+ продолжаются.
