[offtopic] perl (was Re: freebsd - Can't locate nginx.pm)
On 07/08/13 17:34, denis wrote: а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить на центос 5, где эта версия прибита гвоздями и исключает какую-либо замену в принципе кроме насильственной компиляции поверх? У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20 своих модулей. Не полностью конечно, но работы было достаточно. Что мешало оставить эти версии не трогая, кроме ЧСВ? Поддержка большого числа версий perl-а, требует дополнительных усилий от тех, кто поддерживает порты perl-а и Mk/* (а поддержка нужна, потому что инфраструктура портов развивается и иногда требует изменений в портах). Поддерживать 5.10 который вышел в 2009-м и сейчас EoL желающих нет. А вообще текущая стабильная версия perl-а уже 5.18.0 (но в портах пока нет). Если у вас много perl-ового кода, который сложно изменить для работы с новыми версиями perl, то проще сделать так: 1. nginx и весь остальной перловый софт разнести по разным jail-ам (или вирт. машинам, если они есть). 2. В джайле с nginx использовать современный perl В джайле с perl-овым софтом ставить нужный perl не из портов, а через App::perlbrew, а модули ставить через Carton (и не обновлять, потому что рано или поздно столкнетесь с тем, что модулю нужна более свежая версия перла, чем есть). Я поддерживаю некоторый (не очень маленький) объем perl-ового кода и после 5.10 переход на последующие версии требовал простых изменений максимум нескольких строчек кода (с конструкциями, давно объявленными устаревшими типа if (defined(@array)) ). Из того, что я помню - сложным был только переход 5.6 - 5.8, когда сильно поменялась работа с unicode. Ну и полезно иметь тесты. Возможность прогнать make test на новой версии перла экономит время (хотя, конечно не гарантирует отсутствие багов) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [offtopic] perl (was Re: freebsd - Can't locate nginx.pm)
08.07.2013 17:59, Anton Yuzhaninov пишет: Если у вас много perl-ового кода, который сложно изменить для работы с новыми версиями perl, то проще сделать так: Это да, вариант хороший. 1. nginx и весь остальной перловый софт разнести по разным jail-ам (или вирт. машинам, если они есть). 2. В джайле с nginx использовать современный perl В джайле с perl-овым софтом ставить нужный perl не из портов, а через App::perlbrew, Не осилили. У нас на некоторых узлах центось 5, пробовали ставить через perlbrew 5.10, но запустить так и не вышло - оно всегда юзало 5.8. И непонятно, как там модули ставить... Если бы были, кто эту систему осилил и мог советами помочь, может и внедрили бы. а модули ставить через Carton (и не обновлять, потому что рано или поздно столкнетесь с тем, что модулю нужна более свежая версия перла, чем есть). такого вообще не видели. Я поддерживаю некоторый (не очень маленький) объем perl-ового кода и после 5.10 переход на последующие версии требовал простых изменений максимум нескольких строчек кода (с конструкциями, давно объявленными устаревшими типа if (defined(@array)) ). Из того, что я помню - сложным был только переход 5.6 - 5.8, когда сильно поменялась работа с unicode. у нас 5.6 не было, а в 5.8 с юникодом тоже было много нюансов вплоть до того, что сайт рандомно показывал всё то хорошо, то кракозяблы, в результате было куча хаков вставлено. И при переходе на 5.10 потребовался аудит почти всего кода. Ну и полезно иметь тесты. Возможность прогнать make test на новой версии перла экономит время (хотя, конечно не гарантирует отсутствие багов) Согласен, нужно. Но много ли людей вообще знает, как их делать? Думаю, 1%, у кого что-то серьезное и простой недопустим. И потом, тесты надо также писать, сопровождать, обновлять вместе с задачами.. и 100% покрытие нереально, там куча сил только на тесты будет уходить. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
