Насколько «плохо» заменяет / usr / bin / perl на / usr / local / bin / perl в CentOS?

Question

ОТВЕТ: В принципе, это можно сделать без каких-либо серьезных побочных эффектов, если вы скомпилировали свой собственный Perl и сделали это так же, как и ваша ОС. Хотя это не рекомендуемая практика, я могу бегать так больше месяца. Я бы пришел к выводу, что это относительно безопасно, если вы знаете, что делаете.

Сегодня мы пришли к выводу, что нам нужно обновить Perl до 5.10.0. CentOS 5.x поставляется с Perl 5.8.8.

Мы определили, что усилия по сопровождению сценариев с #!/usr/bin/perl были тщетными.

Согласно некоторым установочным материалам на CPAN и в других местах, замена версии perl для ОС не является «хорошей» идеей. Я уже обновил ссылку в /usr/bin/. Итак, мой вопрос, насколько это действительно плохо, чтобы заменить /usr/bin/perl?

Я еще не заметил каких-либо побочных эффектов в наших системах, но я готов исправить ссылку (обратно к 5.8.8), как только возникнет проблема.

Я обеспокоен тем, что в стандартном дистрибутиве CentOS могут быть некоторые модули, которые не включены в исходный код CPAN 5.10.0. Я все еще пытаюсь понять, что это за модули.

Заранее спасибо.

Answer 1

По моему опыту, лучшая практика - это собрать весь свой стек (Perl, Apache, ImageMagick, ...) из исходного кода самостоятельно. Это дает вам полный контроль над тем, какие версии всего используются и когда все обновляется.

Замена /usr/bin/perl на скомпилированный - это дерьмовый выстрел. Операционная система может использовать /usr/bin/perl как часть своего обслуживания или init сценарии, поэтому изменение может привести к блокировке вашего сервера или вызвать странные сбои.

Так что игнорируйте системный Perl, постройте свой собственный и исправьте свои скрипты, чтобы они ссылались на вашу версию Perl.

Answer 2

Как правило, более новые версии Perl5 пытаются поддерживать обратную совместимость со старыми версиями.Но это не на все 100%.Например, сценарий, который зависит от неопределенного поведения в Perl 5.8.8 (что не должно происходить, но иногда происходит), это поведение может отличаться в 5.10.0.Тем не менее, обычно довольно безопасно предполагать, что сценарий, написанный для Perl 5.8.8, будет работать под 5.10.0, при условии, что в нем нет других факторов.

Но обычно есть и другие факторы (модули, совместимость байтов для XS).код и тд).Список возможных ошибок огромен.Это не значит, что кто-то из них поймает вас на этом пути, но есть вероятность проблем.

Если у вас уже есть обновленный Perl в / usr / local / bin, переходитевперед и используй это.Но не разбирайте и не обновляйте старую / usr / bin / version.Это всего лишь небольшой кусок жесткого диска (по нынешним меркам очень маленький).

Кстати, многие люди высоко ценят perlbrew (App :: Perlbrew на CPAN) как инструмент, помогающий поддерживать несколько версий.Perl.

Answer 3

Что ж, если вы решите изменить место, где установлен Perl, это полностью зависит от вас, и там, где вы предпочитаете.Но имейте в виду, что любые сценарии, которые существуют с линией shebang, указывающей на #! / Usr / bin / perl, возможно, сломаются.

Я бы порекомендовал, чтобы после того, как вы его установили, создайте в / usr / bin / perl программную ссылку, указывающую на исполняемый файл для новой версии Perl, которую вы установили.Просто мысль.Это работа вокруг, чтобы не сломать что-либо.

Создание приведенной выше ссылки, безусловно, поможет избежать возможности «заглушить ваш сервер», как указал @Mu.

С уважением,

Джефф